Rogue Actor Disrupts Lightning Network With a Single Transaction

A Twitter user by the name “Burak” (@brqgoo) sent a large swath of the Lightning Network into turmoil on Tuesday morning, when he allegedly created a non-standard Bitcoin transaction that prevented users from opening new Lightning channels (connections between Lightning nodes).

Lightning is a layer 2 network that enables cheaper and faster Bitcoin transactions. Burak’s valid but non-standard transaction caused Bitcoin nodes running an implementation of Bitcoin called btcd, to suddenly stop creating new transaction blocks. This caused a corresponding glitch on all Lightning Network Daemon (LND) nodes. LND nodes rely on information from btcd Bitcoin nodes, and the glitch caused LND nodes to reject all new channel opening requests.

Consensus conflict caused by max Witness Items Per Input #1906

Bitcoin has a consensus rule that limits the number of stack items in a row to 1000. However, a P2TR spend containing OP_SUCCESSx precedes this rule regardless.

I made a P2TR spend containing an OP_SUCCESSx opcode with 500,001 empty pushes, which as a result, caused a consensus conflict between btcd and core:

Changing the max WitnessItemsPerInput parameter from 500,000 to 4,000,000 solves the issue:

Read more: Kollider Raises $2.4M to Build ‘Lightning-Native’ Financial Products

Burak’s shenanigans disrupted a good chunk of the Bitcoin and Lightning ecosystems. Nevertheless, one could argue the community’s anti-fragility was on full display. Core Lightning (CLN) nodes that rely on Bitcoin Core, the most popular implementation of Bitcoin, were unaffected (although this seems to have been by design). Additionally, the bug Burak exploited was quickly patched (thanks to Elle Mouton and Oliver Gugger).

“Burak was well aware of the consequences triggered by the transaction. I think everyone can decide for themselves if that is to be considered malicious or not,” Rene Pickhardt, Bitcoin and Lightning developer and educator, told CoinDesk. Pickhardt co-authored the popular “Mastering Lightning” book and helped demystify many technical aspects of this story.

How should Bitcoin handle bugs and exploits?

Burak’s actions not only sparked lively exchanges on Twitter, but also raised a key question – how should the Bitcoin community handle similar exploits in the future?

“Generally, developers promote a well-known culture of responsible disclosure and ethics when discovering exploitable bugs. Lightning Labs had a reasonable plan for patching this problem beforehand, but maybe Burak felt the situation was more urgent and wanted to light a fire under [them],” John Cavarlho told CoinDesk. Cavarlho is the CEO of Bitcoin software firm, Synonym. The firm’s CTO, Reza Bandegi, also helped clarify technical aspects of this story.

Read more: Bitcoin Software Company Synonym Launches Bitkit, a Bitcon Wallet Powered by Slashtags Protocol

What Cavarlho is describing could be further incentivized by establishing robust bug bounty programs. “It's always hard to prepare against a novel bug. I guess more review and bug bounty programs for responsible disclosure may help.” Pickhardt weighed in. “However as I understand, Pieter Wuille thinks there may sometimes be a risk in fixing bugs, as that may raise awareness and attract potential malicious actors in the transition phase while nodes update.”

Indeed, Bitcoin developer Pieter Wuille thinks the process of fixing bugs and managing exploits is not always straightforward.

“I don't think it's necessarily that simple. It'd be reasonable to assume that exploiting this needed cooperation from miners (or ones with non-standard mempool/relay policy at least), making it harder to pull off. And fixing this one-line without raising suspicion is hard,” Wuille tweeted.

Wuille has a point. Rumors were circulating that Burak paid $700 to F2Pool, one of the largest Bitcoin mining pools, to have his non-standard transaction included in one of their blocks. He then embedded a bizarre message in the transaction, “You'll run CLN and you'll be happy," a reference to Core Lightning (CLN), which, as discussed above, is an alternative to LND, the Lightning implementation affected by the exploit.

“I can't speak for Burak, but it took some special effort and expense to perform his demonstration, so I have to assume he knew exactly what he was doing and that he at least wanted to draw attention to himself, LND, and apparently, CLN too, because he left a supportive message for CLN within the instigating transaction on-chain,” Cavarlho explained.

Christian Decker, a researcher at Bitcoin infrastructure firm, Blockstream, and contributor to the CLN project, distanced his team from the exploit and publicly denounced Burak’s actions.