Full RBF (Full Replace-by-Fee)

What Is Full RBF?

Full RBF (Full Replace-by-Fee) is a mempool policy that allows any unconfirmed Bitcoin transaction to be replaced by a new transaction spending the same inputs, provided the replacement pays a higher fee. Unlike the earlier opt-in RBF system defined in BIP 125, full RBF does not require the original transaction to signal its willingness to be replaced via the nSequence field.

The concept is straightforward: if two conflicting transactions sit in a node's mempool (both spending the same inputs), the node keeps whichever pays more in fees. This aligns mempool policy with miner incentives, since miners are economically rational actors who will always prefer the transaction that generates more revenue.

Full RBF became the default behavior in Bitcoin Core 28.0 (released October 2024) and was made mandatory in Bitcoin Core 29.0 (released April 2025), when the -mempoolfullrbf configuration option was removed entirely. Today, every Bitcoin node running current software treats all unconfirmed transactions as replaceable.

How It Works

To understand full RBF, it helps to trace the history of transaction replacement in Bitcoin.

Original Transaction Replacement

Satoshi Nakamoto's original Bitcoin implementation (v0.1) included a transaction replacement mechanism using the nSequence field. Nodes would replace a mempool transaction if a new transaction spending the same inputs arrived with a higher sequence number. However, this design had no fee requirement, creating a denial-of-service risk. Satoshi disabled the feature in Bitcoin v0.3.12 (September 2010).

Opt-in RBF (BIP 125)

In December 2015, David Harding and Peter Todd published BIP 125, which reintroduced transaction replacement with safeguards. Deployed in Bitcoin Core 0.12.0 (February 2016), opt-in RBF required transactions to explicitly signal replaceability by setting at least one input's nSequence value below 0xfffffffe.

BIP 125 defined five rules for valid replacements:

1. The original transaction must signal replaceability via nSequence
2. The replacement must not include new unconfirmed inputs absent from the original
3. The replacement must pay an absolute fee equal to or higher than the total fees of all transactions being replaced
4. The replacement must pay for its own bandwidth at or above the minimum relay fee rate
5. The number of original transactions plus their in-mempool descendants must not exceed 100

The Shift to Full RBF

Full RBF removes rule #1: the signaling requirement. Under full RBF, the remaining four rules still apply, but the original transaction no longer needs to have opted in. Any unconfirmed transaction can be replaced if a valid higher-fee alternative arrives.

The rollout happened in stages:

1. Bitcoin Core 24.0 (November 2022): added the -mempoolfullrbf configuration flag, defaulting to off. Node operators could opt in individually.
2. Bitcoin Core 28.0 (October 2024): changed the -mempoolfullrbf default to on, enabling full RBF for all nodes unless explicitly disabled.
3. Bitcoin Core 29.0 (April 2025): removed the -mempoolfullrbf option entirely. Full RBF is now mandatory and non-configurable.

Replacement in Practice

When a user wants to replace an unconfirmed transaction, they broadcast a new transaction that spends at least one of the same inputs. The replacement must pay a higher absolute fee and meet the minimum feerate requirements. Nodes receiving the replacement drop the original from their mempool and relay the new transaction.

# Replace an unconfirmed transaction using bitcoin-cli
# The replacement spends the same input(s) with a higher fee

# Check the original transaction's fee
bitcoin-cli gettransaction <original_txid>

# Create a replacement with higher fee
bitcoin-cli -named send \
  outputs='{"<recipient_address>": 0.01}' \
  fee_rate=25 \
  options='{"inputs": [{"txid": "<same_input_txid>", "vout": 0}]}'

Why It Matters

Full RBF resolves a long-standing tension between mempool policy and economic reality. Under opt-in RBF, non-signaling transactions appeared "safe" from replacement, but this safety was always an illusion. Miners had no protocol-level obligation to follow the first-seen rule, and any miner could include a conflicting higher-fee transaction in a block regardless of signaling.

By making replacement the default, full RBF provides several concrete benefits:

• Users can unstick transactions during periods of high mempool congestion by broadcasting a higher-fee replacement, improving the overall fee market efficiency
• The policy honestly reflects Bitcoin's security model: only confirmed transactions (included in a block) carry meaningful settlement guarantees
• Compact block reconstruction improved from roughly 64% success to about 94% with full RBF, because nodes and miners see the same transaction versions, reducing block propagation latency
• Removes a class of signaling-based denial-of-service attacks where adversaries could exploit the inconsistency between signaling and non-signaling behavior

For layer-2 protocols like Lightning and Spark, full RBF is beneficial because it ensures that time-sensitive transactions (such as justice transactions and force-close broadcasts) can always be fee-bumped to achieve timely confirmation, regardless of how the original transaction was constructed.

Use Cases

Fee Bumping Stuck Transactions

The most common use of full RBF is replacing a transaction that is stuck in the mempool due to an insufficient fee. During congestion spikes, transactions with low feerates can remain unconfirmed for hours or days. With full RBF, users can broadcast a replacement with a higher fee to prioritize confirmation. This is an alternative to child-pays-for-parent (CPFP), which requires the recipient to spend the unconfirmed output.

Correcting Payment Errors

If a user accidentally sends to the wrong address or for the wrong amount, full RBF provides a narrow window to replace the transaction before it confirms. The replacement must spend the same inputs, so the user can redirect funds by creating a new transaction that pays the correct recipient (or returns funds to themselves).

Optimizing Batch Payments

Exchanges and payment processors that batch withdrawals can use full RBF to add new recipients to a pending batch transaction. Rather than waiting for the original batch to confirm and then creating a second transaction, they replace the original with an updated version that includes additional outputs, saving on-chain space and fees overall.

Time-Sensitive Protocol Transactions

Layer-2 protocols rely on getting certain transactions confirmed within specific time windows. HTLC timeout claims, penalty transactions, and channel closure broadcasts all benefit from the guarantee that they can be fee-bumped regardless of their original nSequence values.

The Zero-Conf Debate

The most contentious aspect of full RBF was its impact on zero-confirmation (zero-conf) payments: transactions accepted by merchants before they are included in a block. Some merchants, particularly those selling physical goods at point of sale, relied on the first-seen rule as a practical (if imperfect) protection against double-spend attempts.

Under opt-in RBF, merchants could check whether a transaction signaled replaceability. If it did not, they treated it as unlikely to be replaced and accepted it immediately. Full RBF eliminated this heuristic.

Opponents argued that actual double-spend rates were extremely low (fewer than 1 in a million transactions) and that full RBF would destroy a functioning payment use case. Proponents countered that zero-conf acceptance was always a trust assumption, not a security guarantee, and that the low double-spend rate simply reflected a lack of motivated attackers rather than genuine safety. For a deeper exploration of this topic, see the zero-conf Bitcoin analysis.

Ultimately, the Bitcoin Core development community concluded that mempool policy should reflect miner incentives rather than provide a false sense of security. Merchants requiring instant payment finality are better served by layer-2 solutions such as the Lightning Network or Spark, which offer genuine instant settlement without relying on unconfirmed on-chain transactions.

Risks and Considerations

Double-Spend Accessibility

Full RBF makes double-spending unconfirmed transactions trivially easy. Any user can broadcast a replacement that redirects funds to a different address. This is not a new attack vector (miners could always do this), but full RBF lowers the barrier by making it a standard mempool behavior rather than requiring miner collusion or custom software.

Merchants and services that previously accepted unconfirmed transactions must either wait for at least one block confirmation or migrate to layer-2 payment channels that provide genuine instant finality.

Fee Escalation

In theory, full RBF enables fee-bidding wars where two parties repeatedly replace conflicting transactions with higher fees. In practice, this is self-limiting because each replacement costs more than the last, and the economic incentive to continue escalating diminishes rapidly. The replacement rules (particularly the requirement to pay for the bandwidth of the replacement) serve as a built-in brake on runaway fee escalation.

Privacy Implications

Transaction replacement can leak information about the sender. If a replacement changes the output structure (adding or removing outputs), chain analysis tools can correlate the original and replacement transactions to identify change outputs or spending patterns. Techniques like PayJoin can help mitigate these privacy concerns.

Wallet Compatibility

Not all wallets have updated their interfaces to support transaction replacement. Users of older wallet software may be unable to take advantage of full RBF for fee bumping, even though the network now universally supports it. Wallet developers should ensure their software provides clear options for creating and managing replacement transactions.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.