Abstract dark neon background with bitcoin, dynamic lines, lightning. Modern design, cryptocurrency

Lightning Network requiem

Research has recently been published about some glaring vulnerabilities in the Lightning Network, which is the second layer protocol built on top of BTC to overcome the inherent shortcomings of the small block BTC network on the practicality of the protocol being used as a cash or micropayments system. 

The paper published by researchers at the University of Illinois revealed two major attack vulnerabilities endemic in the system, which could be used to inconvenience users by locking them from their money or steal funds outright.

The Lightning Network (LN) was conceived in 2016 as a possible alternative solution to Bitcoin scaling for those that were opposed to just returning the protocol to the original state of having an unbounded block size. To those that believed that keeping the block size restricted at 1MB maximum was essential to preserving the decentralized nature of the protocol, this was a welcome alternative. LN promised a scaling solution that instead put 90% of the transactions off-chain, onto a Layer 2 protocol which did not require the base ledger for transactions, so long as an initial setup of ‘coin lockup’ transactions were made in advance, in what they call payment channels

Much like how you have to preload your debit card with bank transfers or charge up your Starbucks coffee card before you can use it for a purchase, one must lock up your BTC into channels before using it on LN. But unlike your debit or Starbucks card, LN is even a bit more complicated than that. That is because your channels are bidirectional, meaning that you can’t just deposit your locked funds into an account that you can use universally, later on, you actually have to open a channel with a specific counterpart, company, or person. 

In our example, it would be like charging your Starbucks card with Starbucks, but unlike a debit card. Why? Well, your debit card can be used to pay anyone that accepts VISA or Mastercard

Your Starbucks card can only be used to buy coffee from Starbucks. So the difference is the scope of usage available to you depending on who you decide to open up payment channels with. Because LN allows for payment channels to be chained together, a user Alice, who has a channel opened with Bob, who has a channel open with Charlie, will be able to effectively pay Charlie through Bob seamlessly. At least in theory. But reality rarely works out like the theory. 

What effectively happens is that Person A with $100 locked in channels may be able to buy a coffee at Starbucks through LN, while Person B also with $100 locked in channels may not, depending on who they have channels opened with, and the current liquidity state of their channels (which is a fancy way of describing whether or not they are net debtors or creditors on their channels). Suffice it to say, LN is not a simple protocol, with layers upon layers of complications, penalties for breaking the state of the channels, routing finding through channels, routing fees, etc. All just to get around the issue of settling a simple Bitcoin transaction on the main chain, which has the self-imposed artificial block size limit, allowing only those willing to pay high fees to be able to use bitcoin directly.

The two forms of Lightning Network Exploitation

The first form is a grieving attack. Basically, a form of cyber vandalism. 

The research shows that due to the historical congestion characteristics of a block size limited BTC, the backup of unprocessed transactions on the main chain allows for a deliberate denial-of-funds attack on LN called a ‘zombie attack.’ It simply means that attackers could open up many channels, await a time of high congestion on the BTC network, and then switch their LN nodes to be unresponsive. 

If their channels include many of the main LN payment routes, this could effectively prevent many LN users from being able to access or move their BTC. Worse still, the only recourse for such an attack would be for the users to try to force close their unresponsive channels on the main BTC network. If the time of the attack is taking place during a high congestion period, the addition of millions of LN users trying to close their channels at the same time would only serve to exacerbate the issue, causing a negative feedback loop, which could end up seeing delays of up to 500 blocks or several days, and fees skyrocketing. 

Only the rich are willing to pay $50 or upwards in fees per transaction can get their transactions processed in times like these, hardly an equitable monetary system for the unbanked and certainly not the micropayment network envisioned by Satoshi Nakamoto in the Bitcoin White Paper. This negative feedback effect (where the response to the attack ends up making the situation worse) is inherent in a block size limited BTC protocol. LN just makes it more complicated by adding extra back pressure during these times of high network congestion.

The second form of attack is more worrying. 

Rather than being just a form of vandalism or inconvenience, the researchers modeled how many nodes would have to collude to effectively steal funds during such times of historical congestion on the BTC network, with the current topology of the LN network. (Spoiler alert: it’s just 30). This attack is a form of double spend attack where attackers on LN deliberately try to publish invalid closing channel transactions to the main chain in their favor. 

For instance, if a channel had an original balance of 5-5 for Alice-Bob, meaning that they each put in 5 of their own money into the channel, but through the course of some payments, the channel has the latest state of 10-0. Meaning that even if Alice has all the coins on her side, Bob could still try to publish an old channel close attempt with the state of 5-5, the initial state. This would normally be detected by something called ‘Watchtowers’ which are community-run services looking out on the network for these fraudulent close transactions, and publish a ‘punishment’ transaction which would penalize Bob for his attempt to steal five coins from Alice. 

However, as the paper illustrates, it is possible that concerted flooding of many of these such attacks coinciding with times of congestion on the BTC network meant that it was possible to front run the punishment transactions and effectively double spend the coins on the main network, so long as one paid a high enough fee to have the BTC miners prioritize the fraudulent channel closing transactions. After all, the BTC miners have no idea what is a fraudulent or stale LN channel transaction versus a valid one. This is the inherent flaw of separating the security model of the transactions into long-lived payment channels on LN.

If this worries you, then it should. LN has been heralded as the future of BTC. But finally, the research is catching up with intuition. Of course, many people warned of the potential of such complications in the security model of LN back when it was introduced, myself included. But whether or not it was because it was convenient, or whether it was well-funded, the LN experiment was bound to be explored because the false narrative unfortunately still exists to this day that Bitcoin cannot risk unlimited block sizes since it would crumble under the weight of its own success. BSV has proven this theory completely inaccurate.

Nature always finds a way, but man will always try to find a way to stop it.

/Jerry Chan
WallStreet Technologist

Watch the BSV Global Blockchain Convention Dubai 2022 Day 1 here:

Watch the BSV Global Blockchain Convention Dubai 2022 Day 2 here:

Watch the BSV Global Blockchain Convention Dubai 2022 Day 3 here:

New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.

[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]