Lightning is doomed. High fees from Ordinals have killed all hope of scaling Bitcoin non-custodially, there is no chance at all that people will be able to cost effectively open channels or enforce hung payments on-chain when necessary. It’s all over, pack it all up guys. Time to start shopping around and deciding whether Coinbase or Cashapp is a better platform for all of our Bitcoin needs now that we can’t afford to do it directly on-chain in a high fee environment.
It was fun while it lasted. We’ll always have the pixelated dick pics on the Lightning art site, the Lightning torch meme where everyone was scared to send it to people in countries the state told us is full of nothing but bad people, we’ll still have the zapping sats from custodial account to custodial account. Into the era of walled gardens we go!
If you took any of that seriously on any level go look at yourself in the mirror, and then give yourself a good hard slap in the face.
Clearing The Gaslighting Fumes
The original Lightning Network whitepaper specifically defined in the conclusion to the paper that for 7 billion people to be able to open two channels a year Bitcoin would require 133 MB blocks.
There is an entire section of the whitepaper called “Risks” (Section 9), that spells out all of the major problems people think means Lightning is “doooooooooomed” because of high fees. The first section of the paper discusses timelock windows. “Improper Timelocks.” This is essentially the dynamic of fee rates versus confirmation time that has become a large concern lately. When you route a payment over the network, you define a success path based on a hashlock preimage, and a clawback path based on the refund timelock window. If fees get higher, that timelock window needs to be longer to guarantee that a preimage spend (the transaction succeeded) doesn’t fail to confirm before a refund transaction becomes spendable.
I.e. if you have to confirm a successful payment on-chain the timelock on the refund path has to be long enough that you can confirm the successful payment path before your channel counterparty can claim the funds through the refund path. How long that timelock window has to be increases the higher feerates get, because the transaction fee decided ahead of time for pre-signed channel closure transactions can be too low to confirm as fast as you expected when you signed them.
Many people are freaking out and losing their shit over this dynamic as if it is some new realization, and it spells the doom of the Lightning Network. This was literally described as a risk in the original whitepaper specifying the first version of the Lightning protocol. It explicitly even described the opportunity cost trade-off from an economic point of view: “There is a trade-off between longer timelocks and the time-value of money.”
The next section is called “Forced Expiration Spam.” It describes the general concept of the Flood and Loot Attack. An adversary opening a large number of channels and closing them all at once on-chain, specifically to take advantage of the fact that if the feerates got too high refund transactions could have a chance at double-spending success path transactions if something needed to be enforced on-chain. If you have a bunch of channels open with payments in mid-flight, and you close them all at once and drive fees up high enough, then every channel counterparty who has to confirm a successful payment on-chain could find themselves in a doublespend race if the fees are driven up high enough to let the timemlock transaction become valid before the successful one with the preimage is confirmed.
If you have enough channels open, and drive fees up high enough, you can profit from this. It was literally described in the whitepaper as an architectural concern. Depending on which version of the paper you count, this class of attack was described in 2015-2016. It wasn’t formally modeled and introduced into the news cycle of this space until 2020.
The whitepaper described data loss, the situation of losing the pre-signed closure transactions and penalty keys for old states that would allow a malicious channel counterparty to steal your funds if they were aware of this. It brought up the situation of being incapable of broadcasting a penalty transaction, and the potential for watchtowers to solve this as a third party being paid to watch the blockchain and submit those transactions on your behalf. It literally described miners censoring channel penalty transactions as a risk, and suggested miner anonymity (and implicitly decentralization) as the mitigation for that risk.
But this is all new information. The Lightning Network is doomed to failure because no one saw any of these problems coming!!!!
The Blockchain You Idiots
Well, I guess we can just admit historical context is lost. Reason is lost. Logic and rationality is lost. We are in a reality where we are going to pretend like historical warnings don’t exist, no one ever pointed out obvious problems destined to manifest in the future, and this is all just totally uncharted territory where no one ever thought about how things would play out.
What is the title of Section 9.6? Oh: Inability to Make Necessary Soft-Forks.
The original whitepaper explicitly spelled out the inability to coordinate soft forks as a risk to the success of the Lightning Network. Are you surprised? Have you never read any of this before? Personally I’m getting déjà vu.
I remember years and years ago, a large contingent of Bitcoiners screaming that the blockchain itself was hitting scaling limits, that it would fail unless we fundamentally altered the entire nature of the decentralization trade-offs of the system. Blockchains were fundamentally useless if people couldn’t directly submit all of their transactions on-chain and have them cost effectively confirmed.
The entire foundation of the Bitcoin ecosystem was rocked to its core when people started arguing over the cost effectiveness of the blockchain at scale, that was literally the entire cause of the blocksize war. What was at the core of this disruption? People’s expectations of what role the blockchain would play in the puzzle of Bitcoin’s evolving ecosystem. Everyone is going to buy their coffee on-chain at a cost-effective feerate, or Bitcoin is a total failure.
Everyone with that mentality just completely misjudged the entire situation. They were trying to stuff a square peg into a round hole. It’s the exact same thing with Lightning.
Square Peg, Round Hole
The blockchain was sorely misjudged, it was really just a place to put channel openings and closings, not a place to buy your coffee. There’s no real chance that people misjudged Lightning though, that is surely the place to put your coffee payments. No one could possibly have misjudged that this time. See how silly that sounds when you put it like that in proper context? Lightning has issues with enforcing payments on-chain; if the value of the payment is less than the fee to submit the transaction to the chain, this is a problem. It makes no economic sense to try to enforce it on-chain. This was a very well known problem. It’s essentially the exact same problem of low value payments happening directly on-chain, except in the optimistic case things just work because people cooperate off-chain. But when they don’t cooperate, there are problems.
This problem was so well known that there was actually a good deal of debate years ago about a solution to it with different trade-offs, packetized payments. If an HTLC is too small to be able to enforce trustlessly on-chain, you can stream a payment sat by sat (or larger chunks of sats) in a trusted manner, and stop streaming and pick another route if someone in a hop decides they’re going to steal a sat from you. The idea is that while it is a trusted payment routing mechanism, you can only lose a few sats to an attacker who steals a tiny piece of your payment, and if someone steals from you while routing a payment you just never route through those nodes again. The citation above is from 2019, but this idea was discussed earlier than that.
Lightning has a problem! (And also a solution to that problem most people reading probably never heard about). All of these issues people seem to think means the sky is falling are issues well understood from the very beginning of Lightning. This begs a question: were we wrong again?
Not wrong in the sense that Lightning is a doomed dead end, but wrong in the sense that Lightning is not going to be used long term in the way we thought it was initially, just like the blockchain itself. We already see Lightning dominated by custodial applications, and people are working on deploying things specifically designed to sit on top of Lighting. Chaumian ecash mints, Uncle Jim setups like LNBits where people are given a custodial account on someone’s Lightning node. We even have proposals like Ark being built out in the proof-of-concept phase on Liquid, which can interact atomically with Lightning payments.
What if Lightning isn’t going to be the killer protocol that consumers directly interact with in order to make their payments online? What if, just like the blockchain itself, it simply winds up being a piece of a settlement layer that other things are built on top of?
Would that be the end of the world? Would that be a failure of Lightning? I would argue absolutely not. From the very beginning of development on Lightning it was incredibly clear what its scaling limitation would be. The whitepaper literally brings up the issue of not getting support for softforks needed in the future as a limitation of Lightning’s potential scalability.
Lightning is proving definitively right now that it can function as a layer for interactivity between different custodians, and that it works smoothly and very effectively for that. There is no reason at all Lightning cannot function as a similar connectivity layer for other layer twos that have superior trust models than a explicit custodian. If channels are not something individuals can cost effectively have for their daily spending activity, that doesn’t mean they are not cost effective for LSPs who run new protocols in addition to Lightning to link between each other, allowing their users to interact with each other. Arks, Statechains, and whatever new ideas people develop over the coming years.
It can be a translator layer for other systems that scale the end users ability to onboard and transact on those layers, exactly like we wound up realizing the blockchain would have to be. And there is nothing wrong with that.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.