bitcoin-dev

Analysis of Replacement Cycling Attacks Risks on L2s (beyond LN)

Analysis of Replacement Cycling Attacks Risks on L2s (beyond LN)

Original Postby Antoine Riard

Posted on: May 17, 2024 03:30 UTC

The detailed exploration of non-lightning Bitcoin use cases susceptible to replacement cycling attacks, primarily from a denial-of-service (DoS) perspective, sheds light on the vulnerability within various Bitcoin applications and protocols.

This vulnerability is highlighted through the mechanism of a replacement cycling attack, which aims to delay transaction confirmations through a series of replacements, thereby enabling double-spending of a hash time-locked contract (HTLC) preimage. A specific scenario involving a channel topology between Mallory, Alice, and Mallet illustrates how an attacker can exploit this method to delay confirmations and facilitate double-spending.

The conditions conducive to the exploitation of such attacks include shared or joined UTXO spendings, where multiple users share spending paths in a transaction, and pre-signed transactions that are executed without further user interaction but are bound by absolute or relative timelocks. These characteristics are foundational to several Bitcoin applications and protocols, including coinjoins and lightning networks, underscoring the importance of understanding the security models and vulnerabilities associated with multi-party applications and contracting protocols.

Further examination reveals the risks associated with transaction-relay and mempool mechanisms, specifically how they can be manipulated to initiate a time-value DoS attack. This type of attack focuses on paralyzing the execution of a targeted application or protocol, leading to either prolonged service disruption or wasting the on-chain time value of coins. The lightning network, despite having lightweight anti-DoS measures, remains vulnerable to such attacks, particularly in scenarios where HTLC funds cannot be recovered due to deliberate interference with transaction confirmations.

The risks extend beyond denial of service to include potential loss of funds, especially in protocols reliant on timely transaction confirmations driven by absolute or relative timelocks. This vulnerability underscores the need for a comprehensive understanding of the implications of mempool policy changes on security models. Additionally, the discussion touches upon various second-layer solutions and use cases, like on-chain Discreet Log Contracts (DLCs), coinjoins, payjoins, wallets with time-sensitive paths, peerswap, submarine swaps, and batch payouts, highlighting their susceptibility to either loss of funds or time-value DoS risks under specific conditions.

In conclusion, the phenomenon of transaction-relay jamming poses significant challenges to both the security and functionality of Bitcoin applications and protocols. The ability to interfere with or halt the relay of time-sensitive transactions not only exposes users to financial risks but also compromises the integrity and reliability of affected services. This analysis emphasizes the complexity of diagnosing and mitigating such vulnerabilities within a decentralized ecosystem, pointing out the unique challenges faced in developing and disseminating mitigation strategies across diverse codebases and user configurations.