Transaction replacement

Transaction replacement occurs when a transaction seen by a node is conflicted with and ultimately replaced by another transaction. Typically, the replaced transaction had been unconfirmed, though it can happen sometimes in a blockchain reorganisation that a transaction with a few blocks confirmation can also be replaced. Transactions in the canonical blockchain must always replace conflicting transactions (a blockchain with two conflicting transactions is invalid).

Unconfirmed transactions that do not conflict with the blockchain can, however, be replaced by other unconfirmed transactions at the whim of nodes, determined by the node operator's own policies. Hypothetically, a node could also keep track of and relay multiple conflicting transactions, though this is not typically done due to DoS risks. Most of this article focuses on this replacement of unconfirmed transactions, since the consensus rules are fixed and unlikely to change ever.

Unconfirmed transaction replacement has been included in the first version of Bitcoin but was disabled in the 0.3.12 release with the comment, "Disable replacement feature for now". Since then, there have been various attempts to make transaction replaceability widely available again.

Beginning with Bitcoin Core 0.12.0 (released Feb 2016), one type of transaction replaceability, replace-by-fee (RBF), became widely available. This page attempts to document the current state of transaction replaceability for wallet authors who want to use that feature.

Node policies

Unconfirmed transaction replacement is optional (it is not, and cannot be, a consensus rule), but widespread adherence to the same or similar policies among nodes can help predict popular network-wide mempool policies with the following expected benefits:

• Consistent policy makes it easy for wallet authors to write code that uses transaction replacement to provide usability-enhancing features.

• Consistent policy helps ensure long-running mempools contain mostly the same transactions (mempool consistency), which makes it easier for wallets and nodes to make guesses about how long it will take a transaction to confirm.

• Consistent mempools may help nodes more quickly validate newly-received blocks as well as reduce the bandwidth used to announce new blocks in the future.

"First seen" / replacement-adverse

The so-called "first seen" policy simply does not perform replacements at all (except as required by the consensus rules when a block confirms a conflicting transaction). A miner using a "first seen" policy can still end up mining a replacement in two notable cases:

1. If the miner saw the "replacement" first. This can be easy to arrange. From the miner's perspective, no replacement occurred, but that is not necessarily the case for other users.
2. If another miner produces a block that confirms a conflicting transaction, this policy discards the first-seen transaction in favour for the confirmed one (required by the consensus rules). Note, however, that even if the block confirming the replacement is later reorganised away, the replacement transaction it confirmed is still preferred to re-mining by a miner using this policy, even if it had replaced another it saw first.

Sequential

The sequential policy was used originally by Satoshi's Bitcoin node software, and simply allows any later transaction to replace an earlier one (indicated by the "sequence" counter in the transaction). This policy has a risk of denial-of-service attacks on nodes, and therefore hasn't been supported since 2010.

Replace by fee (RBF)

The DoS risk in the sequential replacement policy was addressed in 2015 by the concept of requiring transaction replacements to include a higher fee. While fees cannot compensate nodes for the cost of performing the replacement, it is presumed to be paid eventually to a miner, and as such acts as an effective rate limit on any would-be attacker.

Despite fully addressing the dangers of the sequential policy, its deployment was met with resistance by people who have grown accustomed to the intermediate replacement-adverse policy and (irrationally) imagine transaction replacement to endanger their acceptance of unconfirmed transactions. As a result, several variations were proposed (the original is sometimes called "full RBF" or "unconditional RBF").

"First-seen-safe" RBF

"First-seen-safe" RBF (FSS-RBF) limits replacements further, by requiring the replacement transaction to pay at least the same addresses in the same amounts.

The downside to this approach is that it effectively requires adding additional inputs to fund any additional outputs or fees, rather than simply reducing change. This increases transaction size, and therefore also fees (beyond the increase required by RBF). Arguably, it negates the benefit of replacement, making it comparable to child-pays-for-parent (non-replacement) policies.

Time-based RBF

Another policy proposed was to enforce the "first-seen" policy for a certain number of blocks after the transaction was initially seen, and afterward allowing its replacement by RBF only if that transaction has failed to be mined.

Opt-in RBF

BIP 125 proposed a way for transactions to use their "sequence" number to signal their preference for handling with a "first-seen" or RBF policy.

Nodes supporting an opt-in RBF policy therefore switch the policy they use based on the preference indicated by the would-be-replaced transaction.

Note that node software often does not implement the RBF rules proposed by BIP 125 exactly, with small variations considered preferable in practice (or sometimes accidental).

Software support for replacement policies

Software	First-seen	Sequential	Full RBF	FSS-RBF	Time RBF	Opt-in RBF
Bitcoin 0.1 - 0.3.11	No	Exclusive	No	No	No	No
Bitcoin 0.3.12 & later	Prefer	Disabled (DoS risk)	No	No	No	No
Bitcoin Core 0.3.20 - 0.11.x	Prefer	No	No	No	No	No
Bitcoin Knots 0.3.21 - 0.11.x	Prefer	No	No	No	No	No
Satoshi RBF 0.8.6 - 0.10.x	No	No	Prefer	No	No	No
Satoshi RBF 0.11.0	No	No	Prefer	Yes	No	No
Satoshi RBF 0.11.1 & later	No	No	Prefer	No	No	No
Bitcoin Core 0.12.0 - 0.18.x	Yes	No	No	No	No	Prefer
Bitcoin Knots 0.12.0 - 0.15.1	Yes	No	Yes	No	No	Prefer
Bitcoin Knots 0.16.0 & latter	Yes	No	Prefer	No	No	Yes
Bitcoin Core 0.19.0 - 23.x	No	No	No	No	No	Prefer
Bitcoin Core 24.0 & later	No	No	Yes	No	No	Prefer

See Also

• Fee bumping
• BIP 125
• Reddit: Questions about opt-in RBF