Replacement Cycling Attacks: Lightning's Mempool Achilles Heel

Replacement cycling is an attack against CPFP fee bumps that allows an attacker to **remove an unconfirmed transaction from node mempools without leaving an alternative**. It exploits Bitcoin's RBF (Replace-by-Fee) rules in a way that transaction pinning defenses like v3 transaction relay were speci

20. März 2026March 20, 2026 · 11 Min. Lesezeit11 min read

Replacement Cycling Attacks: Lightning's Mempool Achilles Heel

#bitcoin #lightning #security #privacy #mempool

The vulnerability that made a core developer walk away from Lightning — and the 30 months of incremental defenses that followed.

The Core Problem#

Replacement cycling is an attack against CPFP fee bumps that allows an attacker to remove an unconfirmed transaction from node mempools without leaving an alternative. It exploits Bitcoin's RBF (Replace-by-Fee) rules in a way that transaction pinning defenses like v3 transaction relay were specifically designed to prevent — but can't.

Disclosed by Antoine Riard in October 2023 (CVE-2023-40231/40232/40233/40234), the attack primarily threatens Lightning forwarding nodes — the routing backbone of the network.

How It Works#

The attack requires Mallory to control two nodes on either side of the victim (Bob):

MalloryA → ... → Bob → MalloryB

The Cycle#

  1. Setup: MalloryB receives an HTLC from Bob but doesn't resolve it (neither reveals preimage nor cancels). The HTLC has a timeout — if MalloryB doesn't act, Bob can claim a refund after Δ blocks.

  2. Force close: Bob force-closes the channel and broadcasts his HTLC-timeout transaction to claim the refund.

  3. Replace: MalloryB broadcasts an HTLC-preimage transaction (which spends the same HTLC output) plus an additional input she controls, at a higher feerate. This replaces Bob's transaction via RBF.

  4. Cycle out: MalloryB then replaces her own transaction with one that only spends her additional input — removing the HTLC spend entirely from mempools.

  5. Repeat: Bob can rebroadcast, but Mallory can repeat steps 3-4. Each cycle costs Mallory fees (BIP125 rules require increasing fees), but Bob's refund never confirms.

  6. Profit: If Mallory keeps cycling for Δ blocks, Bob's HTLC-timeout expires on the MalloryA side. MalloryA gets refunded. Then MalloryB confirms the preimage, claiming the payment. Bob loses the full HTLC value.

Why V3/TRUC Doesn't Help#

V3 transaction relay (TRUC — Topologically Restricted Until Confirmation) was designed to prevent transaction pinning by limiting descendant chains. But replacement cycling isn't pinning — it's a replace-then-remove pattern. The attacker isn't bloating the descendant tree; they're using legitimate RBF to first replace, then withdraw. The mempool's own rules are the attack surface.

The Severity Debate#

The disclosure sparked genuine disagreement among top developers:

My assessment: The truth is between the extremes. The attack is theoretically sound and practically feasible against high-value HTLCs, but the economics are fragile — each cycle costs the attacker real fees, and a single failure (Bob's rebroadcast hitting a miner mempool at the right time) means Mallory loses everything she spent. It's not the kind of attack a random script kiddie pulls off; it requires capital, timing, and specific channel positioning.

Deployed Mitigations (2023-2026)#

1. Frequent Rebroadcasting (All Implementations)#

Before disclosure, LN nodes rebroadcast HTLC-timeout transactions once per block or less. Now Core Lightning, Eclair, LDK, and LND all rebroadcast much more frequently. Each rebroadcast costs Bob nothing but forces Mallory to pay incremental RBF fees.

Economics: If each replacement cycle costs Mallory x, Bob has y blocks, and rebroadcasts z times per block, an HTLC is reasonably secure up to approximately x × y × z in value. With default parameters, this puts a meaningful floor on attack profitability.

2. Longer CLTV Expiry Deltas#

Increased timelock deltas give Bob more blocks (more y) to rebroadcast, directly multiplying the attack cost. The tradeoff: longer deltas mean longer waits for payment senders if routing fails. Implementations have repeatedly tweaked these defaults since 2023.

3. Mempool Scanning (Eclair, LND)#

If Bob runs a relaying full node, Mallory's preimage transaction may briefly propagate into Bob's mempool during the replacement cycle. If Bob's LN node monitors the mempool and catches the preimage before the upstream timeout, the attack is defeated and Mallory loses her cycling fees.

This isn't guaranteed — Mallory could target Bob's node specifically to avoid propagation — but combined with frequent rebroadcasting, it raises the probability of attack failure significantly.

4. LND's Deadline-Aware Budget Sweeper (March 2025)#

The most sophisticated defense deployed so far. Matt Morehouse described it on Delving Bitcoin:

This is genuinely good engineering. Making the attack cost 20x the potential gain effectively kills it for economically rational attackers on reasonably-sized HTLCs.

5. HTLC Accountability Signal (January 2026)#

Eclair #3217 replaced the experimental HTLC endorsement signal with an accountability signal (BOLTs #1280). This is part of the broader channel jamming mitigation effort. The idea: "I will hold your reputation accountable for the behavior of this HTLC." Nodes endorse HTLCs from trusted peers, allowing more favorable resource allocation. While not a direct replacement cycling fix, it helps nodes identify and deprioritize HTLCs from potentially adversarial paths.

Proposed But Undeployed Solutions#

OP_EXPIRE (Consensus Change)#

Peter Todd proposed making Mallory's preimage path expire before Bob's refund becomes spendable. If the preimage can only be spent in blocks before the HTLC timeout, the two spending conditions never overlap — and the replacement cycle is impossible.

Status: Riard posted a prototype implementation on Delving Bitcoin (November 2024) and is working toward it. But it requires a consensus change and mempool policy updates — a heavy lift. Competing for soft fork bandwidth with CTV, post-quantum signatures, and BIP-54.

Pre-signed Fee Bumps#

Peter Todd argued for pre-signing HTLC-preimage transactions at multiple feerates (1, 2, 4, 8, ... 1024 sat/vbyte). If MalloryB's preimage spend is pre-signed, she can't add new inputs and therefore can't initiate the replacement cycle.

The tradeoff: requires significant additional state management and interaction during channel updates. But it's a pure application-layer fix — no consensus changes needed.

Miner Transaction History#

Corallo's and Riard's preferred long-term solution: miners (or mempools generally) keep a history of previously-seen transactions and re-try them after replacements. This would catch Bob's timeout transaction automatically. It's the most complete fix but would require significant Bitcoin Core changes and increase memory requirements.

HTLC Output Aggregation (Covenant-Dependent)#

Johan Torås Halseth proposed aggregating all HTLCs in a commitment transaction into a single covenant-restricted output. This changes the HTLC resolution model entirely: instead of individual HTLC outputs that can be targeted independently, there's one output that distributes funds based on proved conditions. This likely requires LN-Symmetry + covenants — a long-term prospect.

The Miner Exploitation Variant (January 2025)#

Riard disclosed an additional dimension in January 2025: a mining-capable attacker can combine transaction pinning with replacement cycling to extract excess fees.

The sequence:

  1. Mallory pins Bob's transaction
  2. Bob fee-bumps (doesn't propagate due to pin)
  3. Mallory receives Bob's fee bump and mines it herself (higher fees than other miners see)
  4. Mallory uses replacement cycling to move the pin to another victim

Optech assessed this as "not a significant risk" — it requires specific circumstances and the attacker loses money if they misjudge network conditions. More importantly, the behavior would be detectable via block monitoring tools. But it's a concerning escalation of the attack's theoretical scope.

Connection to LN-Symmetry#

The replacement cycling attack has an interesting relationship with LN-Symmetry (Eltoo). Gregory Sanders noted in January 2025 that broadcasting old states in LN-Symmetry is analogous to replacement cycling — both involve an attacker trying to prevent the latest state from confirming. But Sanders finds the attack "pretty weak" in LN-Symmetry because:

Daniel Roberts' penalty-based LN-Symmetry variant attempted to further disentangle this, but discovered the "last signer" problem — whoever signs last has exclusive access to the current state, creating its own asymmetry.

Real-World Impact: LND Vulnerability Chain#

Replacement cycling didn't just stay theoretical. It interacted with implementation bugs to create real theft risks:

These aren't replacement cycling attacks per se, but they demonstrate how the HTLC resolution model is a fragile surface. Replacement cycling made the community take this fragility seriously.

The Bigger Picture#

Replacement cycling is really a symptom of a deeper architectural tension: Bitcoin's mempool is a public commons with no persistent state, and Lightning's security depends on timely mempool inclusion of adversarial transactions.

Every mitigation — rebroadcasting, longer timelocks, fee escalation — is working around the fundamental issue that mempools don't remember what they've seen. The base layer has no concept of "this transaction was valid and important; try it again."

The proposed fixes map neatly onto the broader Bitcoin development landscape:

As of March 2026, no in-the-wild theft via replacement cycling has been confirmed. The deployed mitigations — especially LND's 20x cost multiplier — appear sufficient for current HTLC sizes. But the attack remains theoretically open, and any significant increase in HTLC values or decrease in attacker costs could change the calculus.

Bottom line: Replacement cycling is the most important theoretical vulnerability in Lightning today. The mitigations work well enough for now, but the permanent fix requires either consensus changes or a fundamental rethinking of how HTLCs interact with mempools. In the meantime, every LN implementation is playing defense — and doing it better each quarter.

Key Sources#

#bitcoin#fromack#lightning#mempool#privacy#security

Comments

No comments yet. Start the conversation.

Contents

11 sections

  1. The Core Problem
  2. How It Works
  3. The Severity Debate
  4. Deployed Mitigations (2023-2026)
  5. Proposed But Undeployed Solutions
  6. The Miner Exploitation Variant (January 2025)
  7. Connection to LN-Symmetry
  8. Real-World Impact: LND Vulnerability Chain
  9. The Bigger Picture
  10. Key Sources
  11. Related Notes