From 986d207a04d59e11c626f4d662ff0c536acb2206 Mon Sep 17 00:00:00 2001 From: pablo Date: Fri, 14 Jan 2022 09:43:21 +0100 Subject: [PATCH] Stuff --- lightning_node_management.md | 87 ++++++++++++++++++++++++++++++++++++ mastering_bitcoin_notes.md | 20 ++------- 2 files changed, 90 insertions(+), 17 deletions(-) create mode 100644 lightning_node_management.md diff --git a/lightning_node_management.md b/lightning_node_management.md new file mode 100644 index 0000000..205bcaf --- /dev/null +++ b/lightning_node_management.md @@ -0,0 +1,87 @@ +# Lightning Node Management + +My umbrel node is almost in sync with the blockchain so soon I will be able to put my new lightning node into use. These +past days I have been consuming a lot of material on how to prepare the lightning node, with the idea in mind of making +a successful routing node. + +These are the topics that I have in mind: + +- UPS for uptime +- Channel opening strategy +- Channel rebalancing strategy +- Pricing strategy + +## UPS for uptime + +I have learnt through different sources that it is important to have a "good reputation" in order to have more chances +of peers connecting to my node. Now, reputation is rather fuzzy, and varies from simply people observing your node on +1ML or similar pages, to a variety of rankings and scores such as BOS, Lightning Terminal Tiers, 1ML node rank, etc. + +One of the components of most of these scores, and more fundamentally, a strong signal of node quality, is uptime. Plain +and simple, never go down, and if you do, don't spend much time down. + +In order to ensure that my node does a good job in terms of availability, I have been studying the possiblity of using a +UPS. In general terms, an outage is the only relevant (as in both probable and impactful) event that could put my node +down. + +I have been reading up a bit on UPS. By design, they are designed to only provide a few minutes of availability to +securely put services down in the machine that is going to go dry. But since both Banky and my router are super low +consumption devices, I'm actually hoping that a decent UPS could provide a handful of hours of activity if needed. +Notice I'm also including the router in the equation because, obviously, if the internet connection goes down, keeping +Banky on is not enough. + +So I need to: + +- Decide what UPS I should get. The main points here are: + - Price + - Battery capacity + - That it has two sockets. +- Confirm that, in the event of a house-level power outage, the router still keeps connecting to WAN as long as it has + electricity. It would also be good to check with a building/street level outage, but I think simulating that goes + beyond my current capacities. +- Measure empirically how long does the setup last until the node disconnects. + +## Channel Opening Strategy + +Once I get funds in my lightning node, I need to start opening channels. As I do it, they will all be unbalanced, with +all the funds sitting in the local side. I'll have to compensate for that since I don't expect anyone opening towards me +initially (I'm not gonna showcase myself all over the place to get people's attention). But I'll discuss that in another +section. + +So, I need to open channels to people. The key questions are: + +- With who? +- How many sats to put into each channel? + +Regarding channel size: generally, the larger, the better. It helps reduce the impact of onchain fees, offers more +opportunities for keeping things balanced and also enables larger transactions to go through. The downside of making one +channel large is the opportunity cost of having a few smaller channels, which increase the variety of nodes. + +From what I've been reading, anything smaller than 1M sats gives yields more trouble than benefit. So I will keep that +as a minimum size for the channels I open. Question is, how big should the bigger channels be? + +I'm copying a table from the statistics page in 1ML, on 13/01/22: + +| Percentile | Capacity in Satoshis | +| --- |----------------------| +| 1 | __.__2.000 | +| 5 | __._24.900 | +| 25 | __.200.000 | +| 50 | _1.000.000 | +| 75 | _3.000.000 | +| 95 | 14.995.600 | +| 99 | 50.000.000 | + +So, it's clear that going above 0.1 BTC is a pretty rare exercise. I'm planning on allocating 0.2 BTC in total during my +first experiments, so I think I will distribute them in the following way: + +| How many channels | Capacity per channel | +|-------------------|----------------------| +| 1 | 5.000.000 | +| 4 | 2.500.000 | +| 5 | 1.000.000 | +| 10 | 10.000.000 | + +The next question is: who to connect to? + + diff --git a/mastering_bitcoin_notes.md b/mastering_bitcoin_notes.md index 4da65d7..48bd0b2 100644 --- a/mastering_bitcoin_notes.md +++ b/mastering_bitcoin_notes.md @@ -41,25 +41,11 @@ The checksum for this entropy is computed the following way: - Starting from the left, grab one bit of the hash for every 32 bits of length in the original entropy (if the entropy is 128 bits, 128/32 = 4, you grab the 4 first bits of the hash). - -```python - -entropy = "01000010011111001011100101101111001010010110101011011111000001101000110111111001010000101000000110011010110011110110010000011001" -entropy_len = len(entropy) - -import hashlib - -hash_of_entropy = hashlib.sha256(entropy) - -print(hash_of_entropy) - - - - -``` +- I got bored of writing, so I made some code. See `seed_playground.py`. ---------- Another interesting fact: miner fees for a transaction are not explicitly specified anywhere, but are simply calculated as the difference between the -inputs and the outputs of the transaction. \ No newline at end of file +inputs and the outputs of the transaction. +