Replacement Cycling

What Is Replacement Cycling?

Replacement cycling is a class of attack against Lightning Network routing nodes, first disclosed publicly by security researcher Antoine Riard on October 16, 2023. The attack exploits Bitcoin's replace-by-fee (RBF) mempool rules to prevent a victim's HTLC-timeout transaction from confirming on-chain, allowing the attacker to steal the value of a routed payment.

The core insight is that an attacker can use RBF to replace a victim's transaction in the mempool, then immediately replace their own replacement, leaving no conflicting transaction behind. The victim's original transaction simply vanishes. By repeating this cycle, the attacker prevents the victim from reclaiming funds through their timeout path while eventually claiming those funds using the payment preimage.

Riard discovered the vulnerability during Lightning developers' discussions in December 2022 and responsibly disclosed it to all major implementation teams approximately 10 months before the public announcement. Each implementation received its own CVE designation: CVE-2023-40231 (LDK), CVE-2023-40232 (Eclair), CVE-2023-40233 (LND), and CVE-2023-40234 (Core Lightning).

How It Works

The attack requires the adversary to control two nodes positioned on opposite sides of a victim routing node within a payment route. The attacker exploits the fact that each HTLC output can be spent in two conflicting ways: immediately via the preimage (HTLC-success path), or after a timelock expires via the timeout path.

Attack Setup

The attacker (Mallory) operates two nodes: MalloryA and MalloryB. The victim (Bob) is a routing node between them. The payment route looks like this:

MalloryA ──HTLC──> Bob ──HTLC──> MalloryB

Timelock structure:
  Bob → MalloryB: expires at block N
  MalloryA → Bob: expires at block N + delta

MalloryB knows the preimage but withholds it.

The CLTV delta between the two HTLCs gives Bob a window to claim his refund from MalloryB before MalloryA can reclaim from Bob. This is the standard Lightning security model, and it is precisely what the attack undermines.

The Cycling Mechanism

1. MalloryA routes a payment through Bob to MalloryB. MalloryB receives the HTLC and learns the preimage but refuses to settle the payment.
2. As Bob's HTLC with MalloryB approaches its timelock expiry, Bob force-closes the channel and broadcasts his HTLC-timeout transaction to reclaim funds.
3. MalloryB broadcasts an HTLC-preimage transaction that spends the same HTLC output (using the preimage) along with an unrelated UTXO as an additional input. Because this transaction pays a higher fee than Bob's HTLC-timeout, RBF rules cause it to replace Bob's transaction in the mempool.
4. MalloryB immediately broadcasts another transaction that spends only the unrelated UTXO input at an even higher fee, replacing her own preimage transaction. Both Bob's HTLC-timeout and MalloryB's preimage transaction are now gone from the mempool.
5. Bob rebroadcasts his HTLC-timeout. MalloryB repeats the cycle: replace with preimage transaction, then replace again to remove it.
6. After enough blocks pass, MalloryA's timelock on the other channel expires. MalloryA reclaims the payment from Bob. MalloryB then lets her preimage transaction confirm, also claiming the payment value. Bob loses the full HTLC amount from both sides.

Why the Victim Cannot Defend

The attack succeeds because MalloryB's preimage transaction exists in the mempool only briefly before being replaced. Bob may never see it, especially if the attacker times the replacement carefully or if network propagation delays prevent the preimage transaction from reaching Bob's node. Without seeing the preimage on-chain or in the mempool, Bob cannot use it to claim funds from MalloryA on the upstream channel.

Why It Matters

Replacement cycling breaks several foundational assumptions of the Lightning Network's security model:

• Timelock enforcement: Lightning assumes that if a party broadcasts a valid transaction before its timelock expires, it will eventually confirm. Replacement cycling allows an attacker to persistently prevent confirmation without leaving a conflicting transaction in the mempool.
• Mempool visibility: Lightning nodes assumed that if a counterparty reveals a preimage on-chain (even in an unconfirmed transaction), the honest node would observe it and use it to claim funds on other channels. The attack prevents this by cycling the preimage transaction out before propagation.
• Economic viability: the attack is profitable when the HTLC value significantly exceeds the cumulative RBF fees the attacker must pay across all cycles. For high-value HTLCs, the cost-benefit ratio can strongly favor the attacker.

The severity of the disclosure led Riard to step back from Lightning Network development entirely, stating that only a sustainable fix at the base layer could fully address this vulnerability class.

Mitigations

All four major Lightning implementations deployed mitigations before Riard's public disclosure. These measures raise the cost and reduce the reliability of the attack but do not eliminate it entirely.

Aggressive Rebroadcasting

The primary defense deployed across all implementations (Eclair, CLN, LND, LDK) is more frequent rebroadcasting of HTLC-timeout transactions. Under BIP 125 RBF rules, each replacement must pay a strictly higher fee than the transaction it replaces. By rebroadcasting more often, the victim forces the attacker to pay escalating fees for every cycle, raising the cost of sustaining the attack.

Attack cost ≈ fee_per_cycle × rebroadcasts_per_block × CLTV_delta

Example with 80-block CLTV delta and 3 rebroadcasts/block:
  240 replacement cycles × minimum fee increment per cycle
  = substantial cumulative cost for the attacker

Mempool Monitoring

Eclair and LND now actively scan their local mempool for the attacker's preimage transaction during its brief appearance. If Bob's node catches the preimage before it is cycled out, Bob can immediately use it to claim funds from MalloryA on the upstream channel, defeating the attack entirely.

This defense is probabilistic: it depends on the preimage transaction propagating to Bob's node before the attacker replaces it. Network topology and propagation timing affect its reliability.

Longer CLTV Expiry Deltas

Increasing the CLTV expiry delta gives the victim more blocks (and therefore more rebroadcast rounds) to get their HTLC-timeout confirmed. Default values vary across implementations:

Analysis from Bitcoin Optech suggests approximately a 50% chance the attack will fail with a CLTV expiry delta of just 70 blocks under conservative assumptions about mempool transaction persistence.

Proposed Consensus-Level Fixes

Peter Todd proposed OP_EXPIRE, a new opcode that would make the preimage-spending path of an HTLC output become invalid after a specified block height. After the timelock period, only the timeout path would remain spendable, eliminating the root cause of the attack. This would require a soft fork and has received mixed reception from the developer community.

Relation to Transaction Pinning

Replacement cycling is related to but distinct from transaction pinning. Both attacks exploit mempool policy to prevent a victim's transaction from confirming:

• Pinning keeps a conflicting low-fee transaction in the mempool, blocking the victim's higher-fee replacement from entering.
• Replacement cycling removes the victim's transaction entirely, leaving no trace. The attacker's own transaction is also removed, creating a clean mempool state where the victim must start over.

Mitigations for pinning (such as TRUC/v3 transactions introduced in Bitcoin Core v28.0 and anchor outputs) do not directly address replacement cycling, because the attack does not rely on pinning a transaction in place. The disclosure catalyzed broader mempool policy improvements, including Bitcoin Core's decision to enable full RBF by default in v28.0 and make it unconditional in v29.0.

Impact on Layer 2 Security

Replacement cycling highlights a fundamental tension in Bitcoin's Layer 2 landscape: off-chain protocols rely on the ability to enforce on-chain transactions within time-bounded windows, yet the mempool provides no hard guarantees about transaction confirmation. For a deeper analysis of these tradeoffs, see the research article on transaction pinning attacks and the guide to v3 transactions and package relay.

Layer 2 protocols like Spark take a different architectural approach that avoids HTLC-based routing entirely. By using statechains and virtual UTXOs, Spark eliminates the class of mempool-dependent timelocked disputes that replacement cycling exploits, offering an alternative scaling model without the same attack surface.

Risks and Considerations

No Known Real-World Exploitation

As of mid-2026, no verified theft using replacement cycling has been publicly reported. The attack carries significant practical barriers: the adversary must open channels on both sides of the target, sustain costly fee escalation over many blocks, and avoid detection by mempool-monitoring nodes. Large routing nodes' selective peering policies further complicate channel establishment for attackers.

Ongoing Vulnerability

Despite deployed mitigations, the underlying vulnerability remains theoretically viable against high-value HTLCs routed through nodes that lack mempool monitoring. No consensus-level fix (such as OP_EXPIRE) has been activated. The current defenses raise the attack cost substantially but do not close the vulnerability class entirely.

Implications for Routing Nodes

Operators of Lightning routing nodes should ensure their implementation is updated to include rebroadcasting and mempool-monitoring mitigations. Setting appropriate CLTV deltas (at least 72 blocks, ideally higher) and limiting maximum HTLC values per channel reduces exposure. Monitoring tools like watchtowers can provide additional protection for nodes that may go offline during critical timelock windows.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.