pull down to refresh

In the post "How To Optimize Lightning Node Centrality" I've discussed how node operator could make a decision "What is the best next node to open new channel?" using so called betweenness-centrality metric of Lightning Network node graph. I also reproduced some results of preprint “Short Paper: A Centrality Analysis of the Lightning Network” for the 26th conference Financial Cryptography and Data Security 2022.
Here I will try to briefly extend previous post and answer on the question "How to maximize LN fees while preserving as high payment flow as possible?".
On this plot I've put betweenness-centrality metric as a function and Proportional fee as a parameter. All points were calculated while applying these limitations:
  • each payment size has its own pre-generated graph (with payment fees as weights),
  • fees are equal for all channels of the node and change simultaneously.
Here what I have as for recommendation from plotted results for a node with approximately 130 channels. Lines for larger payments have a plateau between 2 - 8 PPM which means that payment flow shouldn't get any penalty when proportional fee changes from 2 to 5 PPM. For smaller payments we can't maximize fee rate while not penalizing betweenness-centrality. However, they aren't inelastic in the same degree as larger payments.
Thanks for attention and your sats in case you upvote this post.
Positioning Strategically One can build an undirected weighted network graph with channel capacities. The benefits of this approach are such that it will have twice as much fewer edges and the graph itself will demand less frequent updates. Positioning the node using this information implies longer-term horizons.
Very well said in that medium article.
reply
Have my sats!
What are your take on having (optional) open share of public node liquidity balance so no need to probe anymore? Something like some nodes today are using max HTLC/channel to "indicate" the available sats on that path?
In my opinion hiding public channels balance is useless and against LN path finding and is not helping at all to have more "privacy".
If you really want to use LN in a private mode, use un-announced (so called private channels or nodes) and / or trampolines channels and be happy.
Path finding algorithm today is really shit.
reply
What are your take on having (optional) open share of public node liquidity balance so no need to probe anymore? Something like some nodes today are using max HTLC/channel to "indicate" the available sats on that path?
I think both things aren't needed if node records failures and uses bayesian estimates for payments in future like suggested by Pickhardt.
If peers trust each other they could share balances, of course. It might be graph overlay similar to Public Hosted Channels which also leverage trust.
reply
Indeed, we have so much to improve on LN.
reply
What's the takeaway message?
reply
Betweenness-centrality allows to optimize fees for well-connected node while minimizing potential decrease in routing volumes.
reply
How to maximize LN fees while preserving as high payment flow as possible?".
Pretend I'm blind and cannot see the chart. What is it telling me? I ask because I can see the chart but am not sure what I am supposed to gather from it.
reply
There is certain in-elasticity across all payment sizes. This is why with growing proportional fee betweenness-centrality decreases rapidly. But if we look more carefully at larger payments starting from 1M sats, betweenness-centrality doesn't really drops between 2 and 8 sats per million. This is the place where we could maximize fee revenue and this is especially good because we measured it for very large payments.
I am sorry I wasn't clear because my intention was to write just fast. I couldn't spend more time on this post, sorry.
reply
That helped me understand it better, thank you!
reply
So far after 12h the flow of payments at 5 ppm is approx the same as it was with 1 ppm fee.
reply