88 lines
4 KiB
Markdown
88 lines
4 KiB
Markdown
|
# 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?
|
||
|
|
|
||
|
|
|