• Replacement Cycling Attacks: Lightning’s Mempool Achilles Heel
  • The Core Problem
  • How It Works
    • The Cycle
    • Why V3/TRUC Doesn’t Help
  • The Severity Debate
  • Deployed Mitigations (2023-2026)
    • 1. Frequent Rebroadcasting (All Implementations)
    • 2. Longer CLTV Expiry Deltas
    • 3. Mempool Scanning (Eclair, LND)
    • 4. LND’s Deadline-Aware Budget Sweeper (March 2025)
    • 5. HTLC Accountability Signal (January 2026)
  • Proposed But Undeployed Solutions
    • OP_EXPIRE (Consensus Change)
    • Pre-signed Fee Bumps
    • Miner Transaction History
    • HTLC Output Aggregation (Covenant-Dependent)
  • The Miner Exploitation Variant (January 2025)
  • Connection to LN-Symmetry
  • Real-World Impact: LND Vulnerability Chain
  • The Bigger Picture
  • Key Sources
  • Related Notes

§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:

• Antoine Riard (discoverer): “This new class of replacement cycling attacks puts Lightning in a very perilous position, where only a sustainable fix can happen at the base layer.” He subsequently stepped back from Lightning development — a dramatic signal.

• Matt Corallo: “The deployed mitigations are not expected to fix this issue; it’s arguable if they provide anything more than a PR statement.” He argued only a base-layer fix (miners keeping transaction history) would truly solve it.

• Olaoluwa Osuntokun (LND lead): Called it “a rather fragile attack, which requires per-node setup, extremely precise timing and execution, non-confirming superposition of all transactions, and instant propagation across the entire network.”

• Bitcoin Optech contextualized: forwarding nodes are already “a Bitcoin hot wallet connected to an always-on internet service — a type of deployment that is perpetually one vulnerability away from having all of its funds stolen.” Replacement cycling adds to an existing risk profile.

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:

• Batches HTLCs with matching deadlines into single transactions
• Linear fee function: starts low, allocates the full budget to fees as the deadline approaches (1 block remaining = total budget spent)
• Result: “With LND’s default parameters, an attacker must generally spend at least 20x the value of the HTLC to successfully carry out a replacement cycling attack.”

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:

• The defender can rebind the latest state to any old state the attacker publishes
• The attacker is “driven to negative EV pretty easily” even with modest defender resources
• No preimage/timeout asymmetry to exploit (the fundamental HTLC problem doesn’t apply to state updates)

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:

• LDK batch processing bug (January 2025): If a channel counterparty could confirm transactions that conflicted with multiple HTLC batches, LDK would only update the first batch. Combined with a 0.1-beta logic change that batched timelocked and non-timelocked HTLCs together, this created a path to actual fund theft. Fixed in LDK 0.1.

• LND excessive failback exploit (March 2025): An attacker sharing a channel with an LND node (pre-0.18) could trick the node into both paying and refunding the same HTLC by forcing a restart at the right moment. This could steal “nearly the entire value of a channel.” Other implementations had independently discovered and fixed this years earlier — but the LN spec didn’t describe the correct behavior.

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:

• OP_EXPIRE competes for soft fork bandwidth
• HTLC output aggregation needs covenants + LN-Symmetry
• Pre-signed fee bumps are the pragmatic application-layer approach
• Miner transaction history is a Bitcoin Core change that nobody has championed

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

• Antoine Riard’s original disclosure (October 2023)
• Bitcoin Optech Newsletter #274 — comprehensive original analysis
• Bitcoin Optech Newsletter #339 — miner exploitation variant
• Bitcoin Optech Newsletter #346 — LND sweeper defense
• Matt Morehouse: LND’s Deadline-Aware Budget Sweeper (March 2025)
• Riard: OP_EXPIRE prototype (November 2024)

§Related Notes

• LN-Symmetry - Fixing Lightning’s Foundation — LN-Symmetry’s relationship to replacement cycling
• Bitcoin Covenants - The Next Soft Fork — OP_EXPIRE competing for soft fork bandwidth
• The Great Consensus Cleanup - BIP54 — another soft fork in the queue
• BitVM - Trust-Minimized Computation on Bitcoin — dispute economics parallel
• The CTV Activation Attempt - Bitcoin’s Political Crucible — political landscape for consensus changes