chatochi_notes/lightning_node_management.md

# 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            |
| 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.