pull down to refresh
70 sats \ 3 replies \ @symphonic 24 Apr 2023 freebie \ on: Is Lightning truly "infinitely scalable"? (Understanding HTLCs) bitcoin
483 pending payments at once is a lot, even considering they might take ~500ms each, that's still 1000TPS per node. the theoretical limit is likely smaller though, because of latency involved in filling and emptying all 483 slots.
As we scale lightning, things like channel factories will mean that there are still way more channels than the TPS we need. There are different ways to model this, and it's yet to be seen how different channel constructs will become more and more used or will die off; but just ballpark ~20TPS per channel is very flexible considering most people do <0.001 TPS in their daily lives.
In a model like 6 degrees of separation, we would only need to route through ~6 nodes to get to any destination, something that will only take a few seconds to do. With things like channel factories, this number will likely be closer to 4 or 5.
I believe you greatly overestimate how many transactions need to be processed through one channel at a time to achieve worldwide scalability. We will have a lot of channels by that point.
Fair point, however I still see channel jamming as a potential issue for Lightning. Nothing's stopping you from deciding your HTLCs should take just a little bit longer to settle, locking up the liquidity for the nodes in the path. Darth pointed me to Rene Pickhardt's work, and I found something interesting there:
As many of you know I am currently writing a paper about the fundamental limitations of the scaling abilities of the Lightning Network to conduct Bitcoin payments [3]. Most folks I talk to see deliberate and malicious channel jamming as a problem. While I agree with the problem I think the situation is worse. It is my current understanding that natural congestion resulting from the selfish behavior of both sending and routing nodes will be a huge challenge for the network. This is amplified by the uncertainty (for example about liquidity). However, even without uncertainty it will create an upper boundary of how many payments per second the participants of the network will be able to conduct. This boundary is more or less given by the weighted betweenness centrality of the most central node and the routing throughput that this node is able to handle. More on this is soon to come here...
He posted this in January of this month, so hopefully this paper he's talking about will come out soon. The current proposals for preventing such jamming don't seem great either, from things like credit limits to "reputation tokens". But I trust that LN will evolve and we'll see better solutions
reply
the limiting factor is going to be having liquidity in the right directions across channels, not the latency in managing HTLC slots
reply
I definitely envision tech allowing transactions to be merged/skipped and whatnot between large routing nodes that are processing lots of transactions in both directions through a channel
reply