claude-dev-suite Replacement Cycling Attack
Disclosed by Antoine Riard, Oct 2023. A novel mempool-policy attack against Lightning where an attacker repeatedly cycles RBF-replacing their own malicious child tx, forcing your honest fee-bumping attempts to incur progressively higher costs while their tx sits in mempool, eventually causing your legitimate sweep tx (HTLC-timeout) to miss its CLTV deadline.
The setup
You're routing a payment Alice → You → Bob:
- You have an outgoing HTLC to Bob (Bob owes you).
- You have an incoming HTLC from Alice (you owe Alice).
- Alice's HTLC has earlier CLTV; Bob's HTLC has later.
If Bob force-closes and you can't claim his outgoing HTLC before your incoming HTLC times out → you lose the payment forwarded to Bob but still owe Alice.
The exploit
Attacker (Bob) attempts:
- Bob force-closes the channel; HTLC output appears on chain.
- You publish HTLC-timeout tx (pre-signed) to claim back the funds after CLTV.
- Bob publishes a competing HTLC-success tx using a (potentially recently learned) preimage, with lower fee → your tx and his tx both spend the same output.
- You bump your tx via RBF.
- Bob bumps his tx slightly by replacing his own with a marginally higher-fee version.
- By BIP125 rule 5, each replacement must pay extra per added vbyte.
- Bob repeats step 5, marginally bumping each time.
- Each Bob's bump is cheap; your bump becomes more expensive each round (you must beat his absolute fee).
- Eventually you stop bumping (resource exhaustion), Bob's tx confirms with the preimage. He's revealed it now to you, but you've already paid Alice's HTLC (you trusted the chain to resolve before).
The ATTACK COST to Bob is small (he keeps replacing his own tx with incremental bumps); the COST TO YOU includes both the failed timeout fees and the lost payment to Alice.
Why BIP125 enabled it
BIP125 rule 5: replacement tx must pay extra incrementalrelayfee × size_increase beyond the original. But this allows an attacker who
controls a competing tx to force you to keep bumping ahead of
them, while their own bumps are tiny.
Mitigation 1: TRUC v3 (BIP431)
v3 transactions limit:
- ≤ 1 unconfirmed ancestor.
- ≤ 1 unconfirmed descendant.
- Sibling eviction allowed (no need to pay for sibling's bandwidth).
This breaks the cycling pattern: attacker can't keep stacking replacements with tiny bumps; sibling eviction lets honest party replace cheaply.
Mitigation 2: Ephemeral anchors
Anchor with value=0 and trivially-spendable script. Must be spent
in the same package as parent. Eliminates pinning surface (anchor
isn't independently spendable).
Mitigation 3: Increase pre-signed fee buffer
Pre-sign HTLC-timeout txs with a generous fee. If mempool fee rates spike beyond expectations, you have headroom.
Mitigation 4: Watchtower + witness monitoring
Watchtowers monitor not just for cheating commitments but also for HTLC pinning attempts; can attempt punitive replacement.
Lightning impact
- LDK, LND, CLN, Eclair shipped TRUC v3 + ephemeral anchor support in the channels they create after BIP431 activation (Sept 2024).
- Legacy anchor channels remain vulnerable in theory until they're closed and reopened.
Status
- BIP431 + BIP331 active in mempool policy since Bitcoin Core 28.0.
- Deployed by major LN impls in their post-28.0 release cycles.
- Mitigations are at mempool policy level, not consensus.
Common confusions
- Replacement cycling is NOT the same as pinning (which is about blocking your tx from confirming via large descendants). They share the underlying BIP125 mechanic but exploit it differently.
- Replacement cycling is NOT a flaw in Lightning's fundamental protocol; it's a flaw in pre-TRUC mempool policy that Lightning was relying on.