### Intro

Rene's newest research on measuring the likelihood of payment possibility is up on his Github. He generously provided the code along with the results. He could explain the project much better than I could, but here's the TL;DR.
If you repeatedly perform the following experiment, you create a distribution of amounts that (in a zero-fee network) describe the probability that the network can relay a payment of X satoshis.
The Experiment:
1. Create a graph from an LN snapshot.
2. Sample balances for channels from a uniform distribution.
3. Get the max flow between two random peers.
You need at least 256 samples to get a stable distribution. The more samples, the more better the resolution of uncertainty.

### Feb 2024 Snapshot Results

I ran the code on a newer snapshot of the Lightning Network. Here are the results:
Maximal sendable amounts to guarantee service level objective `P` in the full network & professional subnet
``````  P   |  FULL LN  | Professional subnet
------+-----------+--------------------
99.9% |         0 |       842508
------+-----------+--------------------
99.0% |         0 |      3417123
------+-----------+--------------------
97.5% |         0 |      4828513
------+-----------+--------------------
90.0% |       169 |      8203365
------+-----------+--------------------
80.0% |      7565 |     11583791
------+-----------+--------------------
50.0% |     62731 |     26260636
------+-----------+--------------------
33.9% |    165426 |     40333621
------+-----------+--------------------
``````
Expected Service level `P` in the full network & professional subnet for various target amounts
``````  amount |   FULL LN  | Professional subnet
---------+------------+--------------------
1000 |   88.06%   |    99.99%
---------+------------+--------------------
10000 |   77.62%   |    99.99%
---------+------------+--------------------
100000 |   40.85%   |    99.98%
---------+------------+--------------------
1000000 |   12.29%   |    99.87%
---------+------------+--------------------
``````
`````` Full Network:
===============================
Number of Nodes: 16555
Number of Edges: 58093.0
Total Capacity: 4955 BTC
Average Liquidity per node: 29.0M sats
Average node degree:  3.5
Density: 0.0004

Professional Network:
===============================
Number of Nodes: 1009
Number of Edges: 17000.0
Total Capacity: 3309 BTC
Average Liquidity per node: 328.0M sats
Average node degree: 16.8
Density: 0.0334

``````
Compared to his results for the 2022 snapshot, it looks like pronet can relay payments with 99.9% probability that are order of magnitudes higher than in 2022. In contrast, the full network cannot relay any payments with >97.5% probability. In fact, SLA's for most payment sizes decreased for the full net, except for the larger payments whose SLA's increased slightly.

### Beta Distribution

I also tried sampling from a different kind of distribution for the channel balances. Instead of sampling from a uniform distribution which assigns an equal probability for all possible balances of a channel, I chose to use a beta distribution to describe the balances. Assume for each channel that 40% of the time, the funds are on the left node's side, 40% of the time the funds are on the right nodes side, and 20% of the time the balance is somewhere in between. This scenario can be described using a beta distribution.
Under this assumption, the amounts of that can be relayed at certain SLA levels are generally lower. The effect this assumption had on the results of the older snapshot (not included) were more profound. However, In the newer snapshots, the results for either assumption converge for the lower level SLA's and will most likely continue to do so as the network evolves.
Maximal sendable amounts to guarantee service level objective `P` in the full network & professional subnet
``````  P   |  FULL LN  | Professional subnet
------+-----------+--------------------
99.9% |         0 |       457670
------+-----------+--------------------
99.0% |         0 |      2755395
------+-----------+--------------------
97.5% |         0 |      4331736
------+-----------+--------------------
90.0% |         1 |      7842446
------+-----------+--------------------
80.0% |      2245 |     11383657
------+-----------+--------------------
50.0% |     50456 |     26212081
------+-----------+--------------------
33.9% |    137741 |     40392638
------+-----------+--------------------
``````
Expected Service level `P` in the full network & professional subnet for various target amounts
``````  amount |   FULL LN  | Professional subnet
---------+------------+--------------------
1000 |   83.74%   |    99.99%
---------+------------+--------------------
10000 |   70.34%   |    99.98%
---------+------------+--------------------
100000 |   37.58%   |    99.95%
---------+------------+--------------------
1000000 |   11.12%   |    99.81%
---------+------------+--------------------
``````
Thanks Rene for sharing your code so that it can be experimented with.
related posts
714 sats \ 2 replies \
Interesting to see evidence that professionally run nodes are getting more efficient/reliable while amateur nodes are getting less efficient (in aggregate) compared to a few years ago.
Both RenĂ©'s distribution of channel balances and your beta distribution are making lots of assumptions about the actual liquidity placement in the network and "who wants to pay who".
On some level, who cares if I can't pay some node I was never going to pay anyways? Maybe the amateur nodes aren't actually getting worse at payment reliability? Perhaps they are just optimized for paying hub nodes rather than paying one another.
131 sats \ 0 replies \
Both RenĂ©'s distribution of channel balances and your beta distribution are making lots of assumptions about the actual liquidity placement in the network and "who wants to pay who".
That's fair. I would say Rene's assumption is as nonbiased as possible. I add a little intuition with mine because I have to pick alpha and beta out of thin air. The results are important to mention because the beta distribution is so expressive. You could describe funding behavior between nodes at the network level, node level, or the node pair level when taking balance samples.
On some level, who cares if I can't pay some node I was never going to pay anyways? Maybe the amateur nodes aren't actually getting worse at payment reliability? Perhaps they are just optimized for paying hub nodes rather than paying one another.
IMO the most important outcome of the work are the network level SLAs. I think breaking down which connections contribute to that SLA would give insight as to which nodes are actual 'liquidity service providers' of the network. Once again, you could go down to the node level, or the node pair level.
0 sats \ 0 replies \
On some level, who cares if I can't pay some node I was never going to pay anyways? Maybe the amateur nodes aren't actually getting worse at payment reliability? Perhaps they are just optimized for paying hub nodes rather than paying one another.
Super important point. I am sure when Rene publishes the work he would have it as a limitation/caveat of the research. What can be interpreted, what can't be interpreted. IMO, the purpose of work like this is to invent and share methodology.
21 sats \ 5 replies \
Thanks for sharing it. I'm also running the notebook to understand the approach better.
However, based on my interpretation of the motivation of this work, I would have preferred not to use zombie nodes for the work. w/o zombie nodes, the curve for the full network is going to look slightly better.
Zombie nodes are nodes w/o active public channels. Hashxp is not showing the correct number now. But based on my last week of gossip data, we got less than 9K active nodes.
5 sats \ 4 replies \
But based on my last week of gossip data, we got less than 9K active nodes.
That's interesting!
Do you know if gossip is rebroadcast even if there's no 'change'?
0 sats \ 3 replies \
I run LND, and in the gossip JSON file, I get a list of all the nodes (~16k) and the channels (~60K). When I combine these two files again to check how many positive capacity channels each node has, more than 7K turns out to be without a channel.
Not sure how CLN and LDK graph output looks like? If you have one, let's connect. It would be interesting to see how they compare to each other.
0 sats \ 2 replies \
Oh! I was getting caught up on the word 'active'.
Since the code uses the channels list to make the nodes, only nodes with at least one channel are included in the samples.
In my results, I use LND and I also skip disabled channels.
0 sats \ 1 reply \
yes. that makes sense.
I usually put an additional condition of 'capacity' > 0. This filters out a lot of channels...and consequently nodes.
Value Counts for 'capacity' > 0 and 'capacity' == 0: capacity Capacity > 0 42472 Capacity == 0 13954
10 sats \ 0 replies \
Thanks for your comment! I doubled checked my process and found that channels without policies were also being included.
Here are the updated results:
##### Uniform
``````  P   |  FULL LN  | Professional subnet
------+-----------+--------------------
99.9% |         0 |       843342
------+-----------+--------------------
99.0% |         0 |      3372695
------+-----------+--------------------
97.5% |       971 |      4877749
------+-----------+--------------------
90.0% |      9732 |      8256485
------+-----------+--------------------
80.0% |     23366 |     11592785
------+-----------+--------------------
50.0% |    127162 |     26282557
------+-----------+--------------------
33.9% |    349127 |     41021223
------+-----------+--------------------
``````
Expected Service level `P` in the full network & professional subnet for various target amounts
``````  amount |   FULL LN  | Professional subnet
---------+------------+--------------------
1000 |   97.46%   |    99.99%
---------+------------+--------------------
10000 |   89.74%   |    99.99%
---------+------------+--------------------
100000 |   53.37%   |    99.99%
---------+------------+--------------------
1000000 |   18.82%   |    99.82%
---------+------------+--------------------
``````
##### Beta
``````  P   |  FULL LN  | Professional subnet
------+-----------+--------------------
99.9% |         0 |       168796
------+-----------+--------------------
99.0% |         0 |      2717349
------+-----------+--------------------
97.5% |        37 |      4303082
------+-----------+--------------------
90.0% |      2904 |      7728877
------+-----------+--------------------
80.0% |     13610 |     11114169
------+-----------+--------------------
50.0% |     96065 |     26124278
------+-----------+--------------------
33.9% |    293410 |     40540338
------+-----------+--------------------
``````
Expected Service level `P` in the full network & professional subnet for various target amounts
``````  amount |   FULL LN  | Professional subnet
---------+------------+--------------------
1000 |   93.16%   |    99.97%
---------+------------+--------------------
10000 |   82.67%   |    99.96%
---------+------------+--------------------
100000 |   48.25%   |    99.93%
---------+------------+--------------------
1000000 |   17.37%   |    99.72%
---------+------------+--------------------
``````
##### Network Stats
`````` Full Network:
===============================
Number of Nodes: 12497
Number of Edges: 50551.0
Total Capacity: 4904 BTC
Average Liquidity per node: 39.0M sats
Average node degree:  4.0
Density: 0.0006

Professional Network:
===============================
Number of Nodes: 1009
Number of Edges: 16998.0
Total Capacity: 3309 BTC
Average Liquidity per node: 328.0M sats
Average node degree: 16.8
Density: 0.0334

``````