Replacement cycling
Replacement cycling is an attack against CPFP fee bumps and transactions using SIGHASH_SINGLE that allows an attacker to remove an unconfirmed transaction from the mempools of relaying full nodes without leaving an alternative transaction in its place. It mainly affects multiparty transactions that depend on CPFP fee bumps, such as those used in LN.
Mallory and Bob may share funds, as in an LN channel. Each of them has a unilateral exit transaction (such as an LN commitment transaction) that they can publish onchain at any time to terminate the fund sharing arrangement. To allow either of them to fee bump the transaction, it contains at least one output each of them can spend in a child transaction for a CPFP fee bump.
If Bob wants to terminate the fund sharing, he can broadcast his unilateral exit transaction along with a child transaction for the CPFP fee bump. Mallory has the ability to broadcast her own unilateral exit transaction with a higher-fee child transaction. Because the two exit transactions spend the same inputs, they conflict, and Bob’s lower-fee exit transaction will be replaced in mempools with Mallory’s higher-fee alternative. That’s fine for Bob: in the protocol, he doesn’t care which exit transaction gets confirmed—either transaction will end the fund sharing arrangement.
However, after Mallory’s alternative exit transaction has entered mempools, she can replace her child transaction with another conflicting transaction—this one with no relationship to either exit transaction. This replacement removes Mallory’s alternative transaction, leaving the mempool devoid of any transaction that terminates the fund sharing arrangement.
Bob can broadcast his exact same exit transaction and child transaction from before, but Mallory can repeat the sequence of steps to remove his transaction from mempools—although she’ll need to use a different UTXO or pay a higher feerate to reuse the same input each time. The cycle of Bob rebroadcasting and Mallory re-removing is what presumably gives replacement cycling its name.
Replacement cycling is especially concerning in protocols that use time sensitive transactions. For example, forwarded HTLCs in LN must be resolved within a certain number of blocks. If Mallory is able to use replacement cycling to prevent Bob from resolving HTLCs forwarded to Mallory within a certain amount of time, Mallory can steal from Bob.
Several mitigations for replacement have been deployed by LN implementations. Possibly the most effective mitigation is a combination of Bob frequently rebroadcasting and the use of longer timeouts in protocols such as HTLCs (e.g. increasing the CLTV expiry delta in LN). Additional mitigations have been proposed.
Any transaction that can be replaced in the mempool by a counterparty or third party is potentially vulnerable to replacement cycling if any of the replacement transactions spend an input under the control of the attacker.
Primary code and documentation
Optech newsletter and website mentions
2024
2023
See also
Previous Topic:
Replace-by-fee (RBF)
Next Topic:
Reproducible builds