Hi, this is a question that has been on my mind for a while. A view that's pretty common is that Lightning can theoretically scale infinitely (more nodes means more routes, better hardware means more transactions can be processed per second, etc).
The way a Lightning payment works is something like this: Suppose Alice wishes to pay Carol 1.0BTC through intermediate routing node Bob. Carol generates a secret r, and shares hash(r) with Alice. Alice offers Bob a payment of 1.0 BTC (+ fees) if he can provide the secret r. This is represented as a hash time-locked contract, where Bob can claim the funds if he provides the secret. After a certain timeout though, Alice can claim the funds back.
Bob then creates a new output on the Bob-Carol channel that transfers Carol the 1.0 BTC if she provides the secret r, again with a timelock.
Right now both channels have 3 outputs, the first one has one output for Alice (subtract 1.01 BTC), one for Bob, and the 1.01BTC Hash-timelocked contract. Once the payment has been completed (or expired), this output can be consolidated back again into just 2 outputs representing the balances of each channel participant.
If however, Alice for example becomes unresponsive and refuses to consolidate, Bob has no choice but to unilaterally close the channel, and claim the funds by providing the secret.
How many HTLCs can Bob have at once? Each Lightning Node decides this on their own, but the maximum is 483, because any transaction with more than this # of outputs won't be considered a standard BTC transaction and can't be relayed. This means that at most, each channel can have 483 outstanding payments at any time.
A few years ago, some researchers demonstrated a flood & loot attack on Lightning. If I understand correctly, they generated a large amount of payments after opening channels, and then never completed the payment. Doing this they were able to lock up a large amount of liquidity on the network and forced nodes to force-close their channels. However, if the network is too congested, then it's possible they can't claim the HTLC by providing the secret before the timelock expires (Remember, once the timelock expires, Alice can claim her 1.01 BTC back!). This also allowed them to steal funds from nodes on their simulated network.
However this raises a question. Even without such a malicious attack, isn't it possible that with millions of users, the throughput wouldn't be able to keep up? Depending on your network latency/processing speed, it can take several seconds to settle an HTLC, now multiply that by millions of users. There's also a finite amount of BTC, so there's a limit on how many channels you could even have in total across the entire network.
OP_VAULT might help increase throughput, you could represent all your HTLCs as a "tree" of transactions inside a single output, and then settle them across multiple blocks which would allow you to raise the HTLC limit (see: https://utxos.org/uses/htlcs/). But how much would it really help? What's the actual theoretical maximum TPS of Lightning
Did I get something wrong? Comments are greatly appreciated
Lightning scalability is a function of its channels. To serve more users, more channels (and liquidity) are needed. "Infinitely scalable" means nothing inherently blocking its scalability like in L1 (debatable when it has on-chain footprint).
reply
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.
reply
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
What's the actual theoretical maximum TPS of Lightning
You should check/study Rene Pickhardt work on LN. Especially his short video about how many TPS LN can do. https://www.youtube.com/watch?v=txcjxSRDvqQ
reply
Thanks! Unfortunately the video only covers the case of 1 channel, and I'm assuming the two nodes are relatively close to each other (the majority of payments are settling in <= 0.05 seconds). With just a single payment channel you don't need to create an HTLC either AFAICT (because you're just updating the balance of this one channel). Unfortunately this is not quite as rigorous as I was hoping for. My latency to one of my channel peers alone is around 200 milliseconds (can you tell I have bad internet?), that's not accounting for the latency of that peer to their peer, and so on (until the final destination).
My concern is when hundreds of thousands/millions of people are routing payments, and those HTLCs take around a few hundred milliseconds to settle each
reply
My concern is when hundreds of thousands/millions of people are routing payments.
You have a wrong perspective of how LN payments are done. NOT everybody will "route" payments. ONLY LSPs and public nodes that are running routing nodes will literally route payments. But the majority will NOT use public routing nodes, but just private nodes (mostly mobiles). And these private nodes DO NOT route payments, just make payments.
So your concern is for nothing.
reply
I worded the comment wrong, what I meant was when users are making payments through routes.
And again, when those private nodes make payments, that still requires funds to be locked up across the route until the payment is considered completed and the HTLCs are consolidated, which is what my post is concerned about
reply
You are worried too much for nothing. You also do not take in consideration other aspects:
  • in the Bitcoin standard, people will spend less, only when they really need it. That means less transactions (compared with other payment networks).
  • BTC and LN will always improve. We are just being starting, is too early right now, LN is only 4 years old, is just a small kid, barely starting to walk.
reply