Playing with Lightning Network
Crouching Capacity, Hidden Balance
Playing with Lightning sounds dangerous, but it is fun, and I’m still alive. So are most of my nodes and channels. I’ve built many experimental things on top of LN by now. “Learning by doing” is the path I prefer.
One experiment I’ve been thinking of for a long time is regarding the balances of each channel. You can by design only see the total capacity of a channel, the actual balance is not broadcasted, but kept hidden at all times except for the two nodes that share the channel. So a senders implementation has to try multiple paths finding potential paths that at least has total capacity enough.
Actually, the total capacity isn’t at the moment broadcasted on the network either, you have to ask the blockchain, which makes it even harder for light wallets. Some of them just try without even looking, which works well most of the times. Even if a channel is known to have a capacity of 10Msat you have no way of knowing if it is 5Msat on each end, or if one end is 0.
So, I decided to find out. I’ll finally start probing the network, to see what it really looks and feels like. It will be exciting. Ithink so far analysis like this has only been done theoretically based on the known graph, but never performed in reality.
I based this experiment on my channel balancer. Basically I just needed to change the pathfinder algorithm from balancing my own channels, to probing arbitrary channels on the network. I’ll probably write a story about my channel balancing project later on. Short story: it worked.
So, what the prober actually does is the following:
Pick a random node. Calculate the path to it, including what channels to use etc. Like this, A is the source node and D is the destination:
A->B->C->D
We want to examine the balance between C and D.
So let’s first try to see how much you can push thru all the way to D. You already know the possible upper limit by calculating the minimum channel-capacity on that route. However that is an extremely optimistic value that has nothing to do with what you can push through in reality. Not even theoretically. Consider if each channel had a random balance between 0 and max capacity in your direction, line them up and take the minimum value. It will not even be half of the smallest channel. Also in reality there are many channels today that have 0 on one side or the other. And there are channels that are disabled, and zombie nodes, that we don’t know about but think they are online. So, all things like that makes the calculation rather worthless. We could as well just brute-force starting from the bottom.
Recklessly probing the network
Phase 1: Start with 1000 sat, if it works, double it to 2000, then to 4000, etc. Let’s say you successfully pushed thru 8000 sat, but not 16000 sat.
Phase 2: Try the middle, 12000 sat, which is 4000 sat from both. If that works you increase with 2000 sat, otherwise you decrease with 2000 sat. Then repeat with 1000 sat increase/decrease. Let’s say you end up on 13000 after all this. That number is [approximately] the total amount you can send A->B->C->D.
Phase 3: Next you want to verify that the limit is actually C->D and not B->C, so you increase that 13000 number to maybe 15000 to be sure, and try to push that A->B->C. If that works you can assume the limit of 13000 is the balance between C->D. We made a discovery and revealed the balance.
This approach can be refined once there are better error reports, and a consensus amongst the developers what the errors should look like. But for now an Epileptic Clown Attack produces some useful results.
Rinse and repeat for the rest of the network.
Successful probing takes a lot of time, since most paths don’t work at all. This is probably due to unfortunate balances and the fact that not all implementations signal when a channel is down making them hard to avoid. Given the fact that over 2/3 of the 3000 mainnet nodes are down, there are a lot of channels that are too. Patience we must have.
In addition to probing balance, in theory, this will end up with a more accurate visualizer, only showing channels that actually do forward payments.
So, connections and balances are discovered and verified to work:
Please note that the numbers might be a little, or much, off. Some channels change balance more than others, and things can go wrong. One thing that causes problems is that even if i specify a specific channel, the nodes might decide to route via a parallel channel between two nodes (because the specified channel had too low balance). This is creative but extremely disturbing both for probing and balancing and probably even for AMP payments, and I think the nodes will stop doing that.
There now seems to be a consensus emerging that broadcasting capacity is a good thing especially for light wallets, and that broadcasting balance isn’t hurting anyone. After all, we can obviously probe that anyhow, and so far nobody has been hurt.
Combining that with making failures standardised and more detailed by including balance would pave the way for Atomic Multi-path Payments to quickly find viable paths. The future looks very bright for Lightning Network. Just need to clean up some things and put in some neglected screws.
The growing network of probed lightning can be found here https://www.moneni.com/lightningprobe
