246 lines
No EOL
11 KiB
Markdown
246 lines
No EOL
11 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.
|
|
|
|
---
|
|
|
|
After a couple of conversations with people that roughly knew what they were
|
|
talking about, I have concluded that indeed, a decent UPS should be able to
|
|
keep banky + the home router up and running for more than an hour. Calculting
|
|
the specifics is pretty irrelevant, since there are a lot of real world factors
|
|
that will change results and it's not all that important.
|
|
|
|
I'll simply buy a nice one from pccomponentes and that's it.
|
|
|
|
## 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.
|
|
|
|
----
|
|
|
|
I came
|
|
across [this brilliant post by Jameson Lopp](https://blog.lopp.net/lightning-network-liquidity-management-guide/)
|
|
. Awesome stuff, as it tends to be when he writes it. In it, it gives a
|
|
thorough explanation of his own experience trying to run a routing lightning
|
|
node. There is plenty of knowledge to get from it, but the main points I'm
|
|
keeping in mind for now are:
|
|
|
|
- Avoid channels smaller than 1M sats completely. If possible, do larger than
|
|
10M sats.
|
|
- The rebalance tool by carsten otto works nicely, but only if you don't also
|
|
have an automatic fee setter (or if you do, just make sure that rebalancing
|
|
and fee setting happen not so frequently and with time between both).
|
|
- The swaps on [lightningnetwork.plus](https://lightningnetwork.plus) are a
|
|
good idea and not some random internet scam, so I should look into how to use
|
|
that.
|
|
|
|
A few links to interesting stuff that I got from Lopp's post:
|
|
|
|
- [An article by Alex Bosworth](https://github.com/alexbosworth/run-lnd/blob/master/LIQUIDITY.md)
|
|
, with the usual thoughts. One new idea I had not seen anywhere though: using
|
|
my own node to make payments on the lightning network is a great way to
|
|
rebalance channels that need inbound liquidity.
|
|
- [Node match tool](https://moneni.com/nodematch) to find nodes that increase
|
|
connectivity of another node (mine, basically).
|
|
- [Lightning Terminal page](https://terminal.lightning.engineering/#/) to get
|
|
scores on any node. Good for judging candidates for channel opening.
|
|
- [Lightning conductor](https://lightningconductor.net/receipt), which offers
|
|
liquidity services including a pretty convenient services to open an incoming
|
|
channel with an on-chain transaction.
|
|
|
|
## First night...
|
|
|
|
I'm writing this as I wait for some channels to open successfully. Finally,
|
|
today was the day I started my routing node!
|
|
|
|
As planned, I moved 0.2 BTC from cold storage to the umbrel wallet. I looked
|
|
for a pretty looking node and opened a channel with them and, voila, it worked!
|
|
I opened another, smaller one with another smaller node, but Thunderhub didn't
|
|
let me. I learned that Thunderhub only allows you to have one pending channel
|
|
opening at a time. So I had to wait a bit to create a second one.
|
|
|
|
Once I successfully opened those two channels, I headed to
|
|
lightningnetwork.plus and joined a triangle. It was almost by accident. I was
|
|
checking the triangle swap page when I hit the application button and, boom, it
|
|
was closed. The page was giving me some instructions on how to proceed and I
|
|
kind of just followed through without much thinking. It felt like heaven when I
|
|
saw my incoming partner channel opening towards me. This swaps thingy is great!
|
|
The only issue I see is that my partners quality is pretty low. One of them is
|
|
pretty old, but has almost no capacity. The other one is super new, but is
|
|
growing pretty fast. Oh well, I guess it's better than nothing!
|
|
|
|
I have realised that the fancier swaps are restricted by channel number and
|
|
total capacity, so it seems that I should try to step up my game slowly, always
|
|
trying to get the best possible partners and then letting my fresh open
|
|
channels mature a bit so that I earn some street creed that allows me to get
|
|
into more exclusive swaps.
|
|
|
|
I can already tell it's gonna be quite a few nights of little sleep...
|
|
|
|
## Plebnet tribe
|
|
|
|
Plebnet this, plebnet that... I kept reading about the plebs everywhere.
|
|
Apparently it's just this bunch of people gathering in telegram to open
|
|
channels and help each other out. Old school forum style, like in the P2P
|
|
piracy times.
|
|
|
|
Today I stumbled upon the [plebnet wiki](https://plebnet.wiki/wiki/Main_Page)
|
|
and I found quite a few useful things. When reading this and similar resources,
|
|
I'm realising that there's a lot of people doing exactly the same discovery
|
|
path I am going through with the lightning network. It's very exciting to see
|
|
this happening. Will it blow up exponentially? I keep on dreaming awake with
|
|
that idea.
|
|
|
|
Anyways, for the cool stuff:
|
|
|
|
- I read their hardening page. It seems pretty standard linux security, so I
|
|
don't feel I need to take any extra steps in this topic.
|
|
- [A small guide](https://plebnet.wiki/wiki/Upgrading_Umbrel_Node) on how to
|
|
upgrade umbrel. It seems umbrel is a rather popular choice.
|
|
|
|
## The self-routing trick...
|
|
|
|
I was reading a post on the lightningnetwork subreddit when I spotted a
|
|
brilliant idea. Like all routing nodes wannabe, I will be having troubles
|
|
pretty often with getting remote balance. The only chances to get some are
|
|
swaps (which only provides at the beginning), services like LOOP (which come
|
|
with a hefty fee) and natural flow of payments (which will only happen with a
|
|
lot of time, effort and capital).
|
|
|
|
And there comes this guy and says: "you can also get remote balance by spending
|
|
your money". Brilliant! It's completely true. If I ever need to pay for
|
|
something through the Lightning Network, I can just do it through the node and
|
|
afterwards refill it through the main chain with new btc. Since I can do my
|
|
grocery shopping with bitrefill, that means I have like 300.000sats of weekly
|
|
rebalancing power.
|
|
|
|
So things would go this way:
|
|
|
|
1. Buy a 100€ grocery voucher through bitrefill. Pay the invoice through an
|
|
unbalanced channel of my node. Now I owe Counterweight LTD 100€.
|
|
2. Go grocery shopping with that, cause I need to eat.
|
|
3. When I owe Counterweight LTD a reasonable amount, like 500€, get some BTC
|
|
with my own money and send it to Counterweight LTD wallet.
|
|
4. Done! No debts outstanding and the channels have been rebalanced.
|
|
|
|
It's just great. Basically, I'm playing LOOP's role with myself, so I get the
|
|
same benefit without having to pay their huge fees. Plus, I do my groceries
|
|
with btc. How badass is that?
|
|
|
|
There's a bit of fee paying involved, but it's orders of magnitude inferior to
|
|
what I would incurr with the other methods to get liquidity, so not much of a
|
|
problem.
|
|
|
|
I just need to be tidy with keeping track of the balances and that should be
|
|
it. |