Replacement cycling attacks risk millions in Bitcoin Lightning Network
One week ago, senior Bitcoin Lightning Network developer Antoine Riard quit. At the time, Riard explained his surprise resignation by saying, “Effective now, I’m halting my involvement with the development of the Lightning Network and its implementations, including coordinating the handling of security issues at the protocol level… I think this new class of replacement cycling attacks puts Lightning in a very perilous position.”
Protos reported on his departure, yet the news seems to have had little impact on Lightning’s total value locked (TVL). When the news broke one week ago, there were approximately 5,500 bitcoin ($188 million) in the publicly viewable Lightning Network. Today, that capacity has declined a modest 4% to 5,300 bitcoin ($180 million).
In spite of Riard’s sudden departure due to these critical vulnerability errors, more than 13,000 Lightning node operators continue supporting at least 62,000 open payment channels today.
Indeed, these figures reflect only the publicly viewable Lightning Network. In addition, wealthy or otherwise privacy-focused users will deny channel opening requests to their Lightning channels. The funds in these channels remain hidden from public view.
As a result, there are untold sums in private Lightning networks between peers and institutions that are unknown. Large institutions like Binance, Bitfinex, and OKX use private networks with unknown quantities of bitcoin.
Apparently, replacement cycling attacks are not a ‘five-alarm fire.’
Brief orientation to the Lightning Network
Lightning is a second-layer network that offers quick, cheap bitcoin transactions. The tradeoff is, of course, reduced security and decentralization.
Most users join the Lightning Network by contributing bitcoin through a wallet built by a third party, thereby accepting that wallet’s Lightning implementation, defaults, and configurations.
Fortunately, users can only lose the bitcoin they contribute when opening payment channels into the Lightning Network. As noted above, less than 5,300 of the 19.5 million circulating bitcoin are inside the public Lightning Network.
There are four major implementations of the Lightning Network which are interoperable insofar as users can send and receive bitcoin to one another. Each implementation, however, varies in its default settings and other functions like smart contract tools, wallet support, liquidity, programming language, and other capabilities.
- Blockstream’s Core Lightning (CLN)
- Lightning Labs’ LND
- Acinq’s Éclair
- Block’s Lightning Development Kit (“LDK”)
There are also custom implementations of the above by Kraken, Binance, OKX, Bitfinex, CashApp, River Financial, and other users of the Lightning Network.
What are replacement cycling attacks?
All of these implementations use hashed time locked contracts (HTLCs) to protect users while they transact inside the Lightning network until they exit onto Bitcoin’s base blockchain.
Unfortunately, for months, a suite of vulnerabilities have existed in standard HTLCs to which most Lightning users opt-in when joining the network. Now called replacement cycling — and also known as ‘transaction jamming’ attacks — attackers replace (or jam) legitimate HTLC transaction broadcasts with a never-ending cycle of spam transactions.
In the end, victims’ bitcoin becomes either frozen inside the Lightning Network or stolen altogether.
Lightning Network developer Antoine Riard originally posted a disclosure about the bug on the official Bitcoin-Dev and Lightning-Dev mailing lists.
Researchers at non-profit Bitcoin Optech further discussed this replacement cycling vulnerability.
Developers found the bug in a feature called transaction replacement. This feature can remove one or more inputs in a multi-input transaction in Bitcoin node mempools. Mempools store pending transactions where they’re usually prioritized according to their transaction fee bid. Lightning Network users can use transaction replacement to replace a transaction with two outputs with another that has only one output.
So far, no major theft or loss has occurred as a result of replacement cycling attacks. Not only does the attack require a fluent understanding of the idiosyncratic Bitcoin Script programming language, but it also requires sophistication and interpersonal coordination.
Specifically, an attack would depend on at least two parties sharing control of an unspent transaction output or UTXO. The attacker must wait for the victim to spend an output. Then, the attacker must replace the second party’s transaction with another preimage transaction that doesn’t include the shared UTXO. This move is called a replacement cycle.
In the most sophisticated version of the attack, the attacker secretly broadcasts the nefarious transaction directly to a Bitcoin mining pool operator. This prevents the victim from seeing the theft via public mempools and Lightning watchtowers.
As rational economic actors, mining pool operators usually choose the transactions bidding the highest fees. Unfortunately, this means Lightning Network victims could lose their funds by being secretly outbid by a hacker.
Read more: New Bitcoin Lightning Network bug: Unattributed payment routing
Bug patches and pleas for resolution
According to Riard’s disclosure, developers discovered this vulnerability during a developers’ meeting in December 2022. They’ve been working on mitigations for months. Already, all four major Lightning implementations have patched many of the attack vectors.
Additional mitigations include permission for forwarding Lightning nodes to rebroadcast transactions without paying extra transaction fees. Forwarding nodes could also negotiate longer ‘CLTV deltas,’ or the number of blocks that the channel’s time window remains open. This would give the forwarding node more time to repeatedly rebroadcast the honest transaction, which can drive up the cost of the attack.
The operator of the forwarding node can also run a full Bitcoin node that can scan the mempool for hackers’ transactions that contain the fake preimage generated by the receiving node. If the forwarding node detects the preimage, it can quickly propose to mining pool operators that the honest transaction be included in a block in spite of its inferior bid, thereby defeating the attack.
Despite these fixes, other weaknesses remain.
For example, some of these patches introduce the possibility that neither honest nor dishonest transactions will get confirmed quickly on Bitcoin’s blockchain, which could cause timing issues if the transactions are routed through Lightning forwarding nodes that often go offline.
Many Lightining developers remain concerned.
Matt Corallo opined in commentary on the issue posted to the Bitcoin-Dev and Lightning-Dev mailing lists, “To be clear, the deployed mitigations are not expected to fix this issue, it’s arguable if they provide anything more than a PR statement.” He suggested an additional mitigation involving Bitcoin miners, in which they could retry past transactions in the event of a replacement cycling attack.
Other suggested mitigations included having a forwarding node incrementally increase fees until its refund transaction is confirmed, with one variation involving presigned fee bumps that could be used to preemptively counteract attacks.
In short, the replacement cycling vulnerability primarily impacts forwarding nodes on the Bitcoin Lightning Network. To date, no major theft of funds has occurred. Developers have already patched several bugs and issued software updates to mitigate the vulnerability and they recommend that all Bitcoin Lightning Network nodes update their software to the latest version.
Nevertheless, some warn that the mitigations are imperfect. With some $180 million dollars viewable in the public Lightning Network, black hat hackers eye a jackpot.
A major theft could be just around the corner. Hopefully, work will continue to fully resolve the vulnerability.
Got a tip? Send us an email or ProtonMail. For more informed news, follow us on X, Instagram, Bluesky, and Google News, or subscribe to our YouTube channel.