pull down to refresh
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
the limiting factor is going to be having liquidity in the right directions across channels, not the latency in managing HTLC slots
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
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.