diff --git a/lightning_node_management.md b/lightning_node_management.md index 205bcaf..6ee1d39 100644 --- a/lightning_node_management.md +++ b/lightning_node_management.md @@ -1,8 +1,9 @@ # 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. +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: @@ -13,21 +14,27 @@ These are the topics that I have in mind: ## 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. +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. +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. +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 +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: @@ -36,29 +43,34 @@ So I need to: - 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. +- 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. +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. +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? +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: @@ -72,16 +84,35 @@ I'm copying a table from the statistics page in 1ML, on 13/01/22: | 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: +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 | +| 3 | 2.500.000 | +| 7 | 1.000.000 | +| 11 | 19.500.000 | + +The missing half-million will be used as petty cash for fees. The next question is: who to connect to? +Intuitively, the goal of any routing node intending to place itself in the +network should be to find a place in the graph that's poorly connected but has +a big demand for moving funds. Since reading the future is impossible, and +there is no history of transactions available for anyone to make forecasts on, +it's impossible to assess the demand. +Thus, the only thing one can try is to put itself between different nodes that +are relevant in terms of traffic, but are not properly connected. This means +that simply connecting to the largest nodes won't work, because they are +already very well connected between themselves. I think that, instead, I should +try to connect to both some of the large nodes, but also to a few smaller ones. +Given the channel capacity strategy that I present above, it naturally follows +that to have a few, large channels for large nodes and many, smaller channels +for smaller nodes. + +Ok, this is as far as my intuition goes. Now I'm going to do a bit of research +to try to find out if there are any other factors I'm missing in my thinking. \ No newline at end of file