Replace-by-Fee (RBF) | Bitcoin Glossary | Mapping Bitcoin

Overview

Replace-by-Fee (RBF) allows a Bitcoin user to replace an unconfirmed transaction in the mempool with a new version that pays a higher fee. This is essential for fee management in a dynamic fee market: if a transaction is stuck because the fee was set too low, the sender can create a replacement with a sufficient fee to get confirmed in a reasonable time.

How RBF Works

Scenario: Alice sends a transaction with too low a fee

Step 1: Original transaction stuck in mempool
┌────────────────────────────────┐
│ TX v1: Alice → Bob             │
│ Fee: 1 sat/vB (too low)       │
│ Signal: RBF enabled           │
│ Status: UNCONFIRMED            │
└────────────────────────────────┘

Step 2: Alice creates replacement with higher fee
┌────────────────────────────────┐
│ TX v2: Alice → Bob             │
│ Fee: 15 sat/vB (competitive)  │
│ Same inputs as TX v1           │
│ Status: REPLACES TX v1         │
└────────────────────────────────┘

Step 3: Miners prefer TX v2 (higher fee)
┌──────────────────────┐
│       New Block       │
│  ┌─────────────────┐  │
│  │ TX v2 confirmed │  │
│  └─────────────────┘  │
│  TX v1 is dropped     │
└──────────────────────┘

Opt-in vs. Full RBF

• Opt-in RBF (BIP125) — The original transaction signals replaceability by setting the sequence number of at least one input to less than 0xfffffffe. Nodes following BIP125 will accept replacements only for signaling transactions.
• Full RBF — Bitcoin Core 24.0+ introduced the mempoolfullrbf option, which allows nodes to accept replacements for any unconfirmed transaction, regardless of signaling. As of Bitcoin Core 28.0, full RBF is enabled by default, reflecting the practical reality that unconfirmed transactions were never truly final.

RBF Rules

A valid replacement must:

1. Spend at least one of the same inputs as the original transaction
2. Pay a higher absolute fee than the original
3. Pay a fee rate high enough to cover the bandwidth cost of relay (incremental relay fee)
4. Not replace more than 100 transactions in the mempool

RBF vs. CPFP

RBF and Child-Pays-for-Parent (CPFP) are both fee-bumping strategies, but they work differently:

• RBF — The sender replaces the original transaction (requires access to the sender's wallet)
• CPFP — The recipient (or sender via change output) creates a new high-fee child transaction that incentivizes miners to confirm the parent

RBF is generally more fee-efficient since it does not require an additional transaction, but CPFP can be used by the recipient without the sender's involvement.

Common Misconception

RBF does not enable "double spending" in the malicious sense. The replacement transaction still pays the intended recipient. RBF simply allows adjusting the fee. While a sender could theoretically redirect the payment, this is no different from the inherent uncertainty of any unconfirmed transaction, which is why merchants should always wait for confirmations for significant payments.