What are some arguments to why the bitcoin lightning network isn't scalable to billions of users?

Question

There are arguments to why the current version of the bitcoin lightning network isn't scalable. What are some of the main arguments of why that is?

Lightning can work in a small country like El Salvador, but what if a bigger country comes in. What are the potential issues and how are they being addressed?

And is it true the 2 main creators of the lightning proposal, Joseph Poon and Thaddeus Dryja have left the project?

Answer 1

If I had to boil it down to one single word it'd say the thread of congestions but let be me elaborate:

• The Bitcoin network only supports a capped rate of certain amount of channel opening and closings. Lets assume 250k per day (though I don't know the exact number). This has several consequences: First onboarding billions of users will take time. Second the CLTV deltas in hash time lock contracts need eventually chosen to be really high. Assume for example we had a billion channels and 10% of the channels wanted to close at the more or less same moment for some reason: That would trigger at least 10 million bitcoin transactions (probably more with second stage HTLCs) and would take several weeks to process. Thus the CLTV values in the HTLC scripts should be really hight so that one is able to resolve this securely.
• Another point related to congestion are the traffic limits of payment channels. While a payment channel at first seems only to be bound by TCP/IP network speed this would be too simple. In reality the amount of HTLCs that can be handled by a channel is capped for two reasons: First to save on chain space in case of a forced channel close and second to mitigate fee blackmail attacks. However the settlement of routes takes longer than the individual peer traffic and can in case of remote channel failures and on chain resolving actually take orders of magnitude longer. In this case channels of routing nodes might more quickly receive more traffic that they can handle. Their channels would create a jam which potentially could cascade through the network.

Note that both points mentioned could not only emerge naturally but be created specifically through attacks. While spamming the bitcoin blockchain is rather expensive due to the onion routing mechanism and the fact that failed routing attemps are not charging a fee to jam remote channels.

Another point to mention is the user experience. The Lightning Network Protocol is a rather sophisticated protocol and with more non expert users the chance for making errors increases which is why good application layer software is needed to shield the complexity from users and protects them. Currently good progress is made in that direction but I fear we will need more in the future.

ps: with regard to your second question. Let me answer with a counter question: Is it true that Satoshi Nakamoto left bitcoin? Well in both cases (bitcoin and Lightning network) given the fact that there are numerous pseudonemous contributors we do not know for sure. That being said it seems as if Joseph Poon and Thadddeus Dryja moved on to other projects.

Answer 2

What an "unbelievable coincidence"????

I was just reading these Dryja tweets a few hours ago

https://mobile.twitter.com/tdryja/status/1405550023320997888

(because I was asking/suggesting to him about an idea about Utreexo

https://mobile.twitter.com/ArafatShymaa/status/1406891111860293636)

So regarding the 2nd Q: yes he is objecting something (that I told myself I'll try to find out & read the details later) & even using the hash-tag #onChainGovernance for his voice to be heard louder

I could add only to the answer of ur 1st Q, I mean without further reading, that light nodes r not as secure as full nodes(hold the complete data) or stateless nodes(holds only proofs needed to verify current block, the rest is on a bridge server). Dryja famous Utreexo project is about minimizing proofs to stateless nodes, so maybe (just guessing) he came to this project on the belief they're going to make their nodes stateless & wants him(the whole team) do their best to enhance the performance & compress proof size; then found out they're going for light nodes which obviously not secure enough for governmental data (at least on his opinion)