Full RBF
Full RBF (full replace-by-fee) is a mempool policy in which a node accepts a replacement for an unconfirmed transaction even when the original did not signal replaceability under BIP 125. It is a relay and mining policy, not a consensus rule. Nodes that do not implement full RBF still accept blocks that contain replacements. It is one variant of Replace by fee; other historical variants include opt-in RBF, first-seen-safe RBF, and delayed RBF.
Opt-in history
Bitcoin Core historically applied a first-seen rule: once a transaction was in the mempool, a conflicting higher-fee transaction was ignored unless the original had opted in. BIP 125, deployed in Bitcoin Core 0.12.0, defined that opt-in: a transaction signals replaceability when any of its inputs has nSequence less than 0xffffffff−1 (see nSequence). Wallets that wanted to bump fees set the signal. Wallets that wanted to present an unconfirmed output as final left it unset. The first-seen simplification never bound miners: a miner could always include a higher-fee conflict. As more hash power and more relay nodes treated unsignaled replacements as acceptable, the opt-in bit stopped predicting whether an unconfirmed transaction would remain first.
Policy change
Under full RBF, replacement is still subject to the rest of the node's replacement rules: the replacement must pay a higher absolute fee, a sufficiently higher fee rate, and must not cause unbounded mempool churn (the familiar BIP 125 incentive constraints, with details revised over time). The change is only that the original transaction's signaling is not required. The policy is local. A node with full RBF will relay and, if mining, consider the higher-fee transaction. A node without it will keep the first-seen transaction and will not relay the conflict. Compact block reconstruction is more reliable among nodes that share the same replacement policy.
Full RBF does not make unconfirmed transactions safe. It makes the unsafety uniform: any unconfirmed output can be replaced by a higher-fee double spend that the network is willing to relay. Services that credit unconfirmed deposits do so at their own risk regardless of signaling. Wallets that need to increase a stuck transaction's fee can do so without having set the BIP 125 bit at first broadcast, provided enough of the relay network and miners apply full RBF. Related package policies (limited package RBF, TRUC / v3 transactions) are separate rules about replacing clusters of related transactions; they are not implied by full RBF alone. See Package relay and Replace by fee.
Bitcoin Core 24.0 added the mempoolfullrbf configuration option, defaulting to off (opt-in RBF only). Bitcoin Core 28.0 changed the default to on. Bitcoin Core 29.0 removed the option, making full replace-by-fee the only mempool replacement policy in Core. The Core wallet has defaulted to creating opt-in RBF transactions for some time. Full RBF affects how the node treats transactions created by others, not only its own wallet. Because policy is not consensus, effective network behaviour still depends on what miners currently run.
Bitcoin Core exposed mempoolfullrbf so operators could opt into unsignaled replacements before the policy became the default. Version 28.0 defaulted the option on. Version 29.0 removed the setting so full RBF is simply part of ordinary replacement policy. Older nodes and alternative implementations may still prefer first-seen behavior, which can temporarily split relay paths for conflicting transactions.
Deployment
Merchants that formerly treated BIP 125 non-signaling as a soft finality signal lost that heuristic once full RBF became widespread. Zero-confirmation acceptance policies must assume replacement is always possible at a high enough fee. Fee-bumping wallets benefit because they no longer need to remember to set nSequence at the first broadcast in order to raise fees later on Core peers. Merchants that treated unsignaled unconfirmed inputs as final already faced miner-level replacement risk. Full RBF makes that risk match common relay policy, so zero-conf acceptance remains an explicit business decision rather than an assumption about BIP 125 signaling.
See also
- Replace by fee
- Mempool
- Fee estimation
- Package relay
- Cluster mempool
- nSequence
- TRUC
- Zero-confirmation transaction