Replace-By-Fee (RBF)

What Is Replace-By-Fee?

Replace-By-Fee (RBF) is a Bitcoin mempool policy that allows an unconfirmed transaction to be replaced by a new transaction that spends at least one of the same inputs and pays a higher total fee. When a Bitcoin transaction is broadcast to the network, it enters the mempool: a queue of unconfirmed transactions waiting to be included in a block. If the fee attached to the original transaction is too low for miners to prioritize, the transaction can remain unconfirmed for hours or even days. RBF provides a mechanism to fix this by submitting a replacement with a more competitive fee.

The concept dates back to Bitcoin's earliest days. Satoshi Nakamoto's original Bitcoin client included a rudimentary transaction replacement mechanism, but it was removed over concerns about denial-of-service attacks. The modern opt-in RBF policy was formalized in BIP-125 (February 2016) and later expanded with full RBF support in Bitcoin Core 24.0 (November 2022), which introduced the memfullrbf configuration option.

How It Works

RBF operates at the mempool policy level, not at the consensus level. Bitcoin's consensus rules have always permitted spending the same UTXOs in different unconfirmed transactions: only one can ultimately be mined into a block. Mempool policies determine which version a node keeps in memory and relays to peers.

Opt-In RBF (BIP-125)

BIP-125 introduced a signaling mechanism using the transaction's nSequence field. Each transaction input has a 4-byte sequence number. If any input's sequence number is less than 0xfffffffe (4294967294), the transaction signals that it is replaceable. This is sometimes called "opt-in" RBF because the sender must explicitly set this flag.

// Transaction input structure (simplified)
{
  "txid": "abc123...",
  "vout": 0,
  "sequence": 0xfffffffd  // Signals RBF (less than 0xfffffffe)
}

// Non-replaceable input
{
  "txid": "abc123...",
  "vout": 0,
  "sequence": 0xffffffff  // Final, no RBF signaling
}

The sequence number also interacts with timelocks. A sequence value of 0xffffffff disables both RBF and relative timelocks (CSV). A value of 0xfffffffe disables RBF but still permits relative timelocks. Any value below 0xfffffffe enables both RBF signaling and relative timelocks.

BIP-125 specifies five rules that a replacement transaction must satisfy:

1. The original transaction must signal replaceability (sequence number below 0xfffffffe)
2. The replacement must not include any new unconfirmed inputs that did not appear in the original (prevents pinning attacks in certain scenarios)
3. The replacement must pay a higher absolute fee than the sum of all transactions being replaced
4. The replacement must pay a fee rate sufficient to pass the node's minimum relay fee, and the additional fee must cover at least the minimum relay fee rate for the replacement's own size
5. The replacement can evict at most 100 transactions from the mempool (prevents denial-of-service via cascading replacements)

Full RBF

Full RBF removes the opt-in requirement entirely. When enabled, any unconfirmed transaction can be replaced by a higher-fee alternative, regardless of its sequence number. Bitcoin Core 24.0 added the mempoolfullrbf configuration flag, and Bitcoin Core 28.0 (2024) enabled it by default.

# bitcoin.conf
# Enable full RBF (default since Bitcoin Core 28.0)
mempoolfullrbf=1

# Disable full RBF (revert to opt-in only)
mempoolfullrbf=0

The full RBF debate was one of the most contentious policy discussions in Bitcoin's recent history. Proponents argued that opt-in RBF created a false sense of security: merchants who accepted zero-confirmation payments based on the absence of the RBF signal were relying on a policy that miners had no obligation to enforce. Any miner could include a conflicting transaction regardless of signaling. Full RBF simply made the mempool policy honest about what consensus already permitted.

Opponents argued that opt-in RBF provided a useful social signal. Even if it was not consensus-enforced, the vast majority of miners respected BIP-125 signaling. Removing the opt-in requirement broke workflows for merchants who used the RBF flag as a risk indicator for unconfirmed transactions. For a deeper look at how fees and confirmation dynamics affect Bitcoin, see the fee market dynamics research article.

Constructing a Replacement Transaction

In practice, creating an RBF replacement involves building a new transaction using PSBTs or raw transaction APIs. The replacement spends at least one of the same inputs as the original and adjusts the outputs to accommodate the higher fee:

# Using bitcoin-cli to bump the fee on an existing transaction
bitcoin-cli bumpfee <original_txid>

# Or manually with PSBT workflow:
# 1. Create replacement spending the same inputs
bitcoin-cli createpsbt '[{"txid":"<same_input>","vout":0,"sequence":0xfffffffd}]' \
  '[{"<recipient>": 0.009}]'

# 2. Process, sign, and broadcast
bitcoin-cli walletprocesspsbt <psbt>
bitcoin-cli finalizepsbt <processed_psbt>
bitcoin-cli sendrawtransaction <final_hex>

Most modern wallets abstract this away with a "bump fee" button that automatically constructs the replacement. The wallet reuses the same inputs and recipients but reduces the change output (or adds a new input) to cover the increased fee.

Use Cases

Fee Estimation Errors

Bitcoin fee estimation is inherently imprecise. A transaction broadcast during a quiet mempool period may become underprioritized if a surge of higher-fee transactions arrives. RBF allows users to adjust fees after the fact rather than overpaying upfront "just in case." This is especially valuable for non-urgent payments where the sender can start with a low fee and bump only if confirmation takes too long.

Unsticking Transactions

Without RBF, a transaction stuck with an insufficient fee has limited options. The sender can wait (potentially days during congestion), or the recipient can use Child-Pays-For-Parent (CPFP) to incentivize miners. CPFP requires the recipient to spend their unconfirmed output with a high enough fee to make the package attractive. RBF is generally more efficient because the sender directly creates a replacement rather than relying on the recipient to add a child transaction.

Transaction Cancellation

While Bitcoin transactions cannot be truly "cancelled" once broadcast, RBF provides a practical equivalent. The sender creates a replacement transaction that spends the same inputs but sends the funds back to their own wallet (minus the fee). If the replacement confirms before the original, the effect is cancellation. This is useful for correcting errors like sending to the wrong address, provided the original has not yet been mined.

Lightning Channel Operations

RBF plays a critical role in Lightning channel management. When opening or closing channels, the funding or closing transaction must confirm on-chain. If fees spike between broadcast and confirmation, the transaction can become stuck, delaying channel operations.

Anchor outputs were specifically designed to work with RBF and CPFP. Each commitment transaction includes small anchor outputs that either party can spend to bump the transaction's effective fee rate. This decouples fee estimation from commitment transaction creation: the commitment can be built with a minimal fee and bumped at broadcast time using current fee conditions.

For a deeper understanding of how payment channels handle on-chain transactions, see the research on payment channels from concept to implementation.

Batch Payment Adjustments

Exchanges and payment processors often batch multiple payments into a single transaction to save on fees. If the batch transaction gets stuck, RBF allows the operator to replace it with a higher-fee version without reconstructing the entire batch from scratch. The replacement can even add new payments to the batch, combining fee bumping with new outputs in a single replacement. For background on how Bitcoin's transaction model enables batching, see the UTXO model research article.

RBF vs. CPFP

RBF and CPFP are complementary fee bumping strategies, each with different tradeoffs:

In Lightning Network contexts, anchor outputs enable both strategies. Either channel participant can CPFP the anchor, and the commitment transaction itself can be replaced via RBF if it was constructed with the appropriate sequence signaling.

Risks and Considerations

Zero-Confirmation Payment Risk

RBF fundamentally undermines the reliability of unconfirmed transactions. Merchants who accept payment before confirmation face the risk that the sender replaces the transaction with one that redirects funds elsewhere. With full RBF enabled across the network, the presence or absence of the BIP-125 signal no longer provides any assurance. Merchants accepting on-chain Bitcoin payments should always wait for at least one confirmation, or use a Layer 2 solution like Lightning or Spark for instant settlement. For more on the tradeoffs of zero-confirmation acceptance, see the research on zero-conf Bitcoin.

Transaction Pinning

Transaction pinning is an attack where a malicious party creates conditions that prevent a legitimate RBF replacement from propagating. For example, an attacker can broadcast a low-fee child transaction that spends the output of the target transaction. Because BIP-125 rule 3 requires the replacement to pay more in absolute fees than all transactions being evicted (including descendants), the cost of replacement can be artificially inflated.

Pinning is a particular concern for Lightning Network force-close scenarios, where HTLC timeout and justice transactions must confirm within specific windows. The anchor outputs proposal and ephemeral dust outputs were designed in part to mitigate pinning by giving each party independent fee-bumping capability.

Privacy Implications

Each RBF replacement is a separate transaction visible on the network. Chain analysis firms can observe the replacement pattern and infer that the same entity controls the inputs. The change output address may differ between the original and replacement, potentially linking addresses that the user intended to keep separate. Users concerned with privacy should be aware that fee bumping creates additional on-chain fingerprints.

Wallet Compatibility

Not all wallets support RBF equally. Some wallets do not signal opt-in RBF by default, making replacement impossible under pre-full-RBF policies. Others lack a user interface for constructing replacements. When choosing a wallet for frequent on-chain transactions, verifying RBF support is an important consideration, especially during periods of high network congestion.

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.