It took a decade to fix this Bitcoin Lightning bug

A Bitcoin Lightning bug that has been apparent since October 2016 — just a few months after the network’s launch — has finally been patched.

In May 2016, Elizabeth Stark and Olaoluwa “Roasbeef” Osuntokun co-founded Lightning Labs and its Bitcoin Lightning network node software, Lightning Network Daemon (LND).

However, just five months later, Osuntokun admitted to a serious security vulnerability within LND that would remain unresolved for a decade.

Now, after years of help from innumerable LND contributors, Osuntokun has substantially patched it by merging pull request (PR) 10331.

The “bug” persisted for so long that characterizing it as such is almost nonsensical.

Indeed, it was probably a design tradeoff, or user experience compromise, allowing users to quickly close LND channels in a mostly secure way — except in the rare event of a blockchain reorganization.

Despite being the world’s most popular implementation of Lightning, LND users exiting the layer 2 network have been at risk for years, per the co-founder’s own admission in issue 53.

Ten years of work on this Bitcoin Lightning bug

Again, LND is node software that helps users enter, transact, and exit from Bitcoin’s Lightning network.

When users fund an LND payment channel to join Lightning, they contribute BTC on-chain in order to then transact BTC off-chain with Lightning users.

Once they finish, they use LND software to exit on-chain, settling their BTC “bar tab” of Lightning transactions.

LND payment channel closing transactions, however, have been subject to blockchain reorganization risk per issue 53. Yes, Bitcoin blockchain reorgs have been a risk to LND users for a decade.

Indeed, LND issue 53 was the oldest open issue of the world’s dominant Lightning network implementation.

Read more: Bitcoin Lightning bug allows remote theft of bitcoin via LND nodes

Finally, a patch for LND issue 53

This month, Osuntokun finally scaled confirmation requirements from one to six blocks — proportionately with channel size — such that channel closings with more BTC require more confirmations. 

The more confirmations an on-chain transaction receives, the more secure it is from reorg risk.

In addition to scaling confirmation requirements, Osuntokun also revamped LND’s state machine to detect more subtle risks of chain reorgs, including real-time monitoring of competing channel close transactions, as well as negative (i.e. reorg) confirmations.

To his credit, Osuntokun continued to follow-up on issue 53 for years in an obvious display of commitment to tackling the problem.

Moreover, issue 53 arose during the earliest days of Lightning’s inception when funds at risk were tiny and anything close to its modern state was a theoretical dream.

It’s difficult to say whether a more conservative tradeoff of channel closings speed weighed against an exceedingly unlikely reorg would have unnecessarily hindered the growth of LND and Osuntokun’s venture-backed LND company.

Got a tip? Send us an email securely via Protos Leaks. For more informed news, follow us on X, Bluesky, and Google News, or subscribe to our YouTube channel.