Replace-by-Fee (RBF)

RBF replaces one or more unconfirmed mempool transactions that conflict over the same inputs. Nothing already confirmed in a block is being rewritten, and a replacement has a different txid because its serialized transaction differs.

BIP125 originally standardized opt-in signaling through nSequence values below 0xfffffffe. That signal mattered when default relay required opt-in RBF; full-RBF later removed signaling as a universal precondition for accepting a replacement.

RBF is local mempool and relay policy, not a consensus rule. A miner may include any consensus-valid conflicting transaction, and a full node validates the resulting block independently of which version it previously held in its mempool.

Bitcoin Core applies replacement rules to prevent cheap relay and validation abuse. A candidate must improve the fee outcome of the conflict set and satisfy the node's relay, standardness and anti-DoS constraints rather than merely conflict with an existing transaction.

Absolute fee and feerate are distinct checks. A higher feerate alone is not sufficient when the absolute fee increase does not cover the transactions being evicted and the incremental relay cost; merely adding satoshis without an adequate rate improvement can also fail policy.

Replacing a parent can evict descendants that depend on it, so replacement is not always a two-transaction comparison. Modern policy bounds conflict sets and evaluates package relationships to keep CPU, memory and bandwidth costs manageable.

RBF fee-bumps by replacing the spending transaction itself. Child Pays for Parent (CPFP) leaves the parent unchanged and adds a high-fee child, allowing miners to evaluate the combined package. Which tool works depends on which outputs the wallet controls and how the transaction graph is structured.

RBF is a controlled mempool replacement mechanism; double-spend describes the conflict or an attempt to spend the same UTXO incompatibly. The same conflict mechanics can be used honestly to raise a fee or maliciously to redirect an unconfirmed payment.

Before confirmation, Bitcoin gives no protocol guarantee that the first transaction a merchant sees will be the one mined. Full-RBF makes that limitation explicit: accepting zero-conf is a business risk decision, not Bitcoin finality.

Use getmempoolentry to inspect an unconfirmed transaction and testmempoolaccept to test a candidate replacement against your node's current policy. Bitcoin Core 28 changed mempoolfullrbf to default enabled; getmempoolinfo exposes the node's full-RBF state in releases that retain that field.