Replace-By-Fee (RBF) & BIP 125 Opt-In: Mechanics, Security, and Double-Spend Protection

When a sender wants to adjust the fee of a transaction already waiting in the mempool, they can use Replace-By-Fee (RBF). Unlike Child Pays For Parent (CPFP), which adds a child transaction to the mempool, RBF completely overwrites and replaces the existing transaction in RAM with a higher-fee version.

This guide details the underlying mechanics of BIP 125, its strict validation requirements, and the security implications for merchants accepting zero-confirmation payments.

---

📡 1. BIP 125 Opt-In Signaling

By default, nodes protect unconfirmed transactions against double-spending under the First-Seen Rule (rejecting any transaction that spends inputs already being spent in the mempool).

To allow replacement, a transaction must explicitly signal that it is replaceable under BIP 125 rules.

                              BIP 125 nSEQUENCE SIGNALING

      ┌─────────────────────────────────┐   ┌─────────────────────────────────┐
      │     Standard Transaction        │   │    BIP 125 Replaceable Tx       │
      │  nSequence = 0xFFFFFFFF         │   │  nSequence = 0xFFFFFFFF - 2     │
      └────────────────┬────────────────┘   └────────────────┬────────────────┘
                       │                                     │
                       ▼                                     ▼
             [First-Seen Policy]                     [BIP 125 Policy]
       Rejects conflicting replacements.     Allows overwriting with higher fee.

The nSequence Trigger

A transaction signals opt-in RBF if at least one of its inputs has an nSequence value less than: $$\text{0xFFFFFFFF} - 1 \quad (\text{binary: } \texttt{0xFFFFFFFE})$$

If all inputs have nSequence set to 0xFFFFFFFF (default), the transaction is considered finalized and cannot be replaced using standard BIP 125 rules.

---

📋 2. The Five Rules of BIP 125 Replacement

To prevent spam attacks where a user floods the network with slightly higher-fee replacements to tie up validation CPUs, Bitcoin Core enforces five strict rules before a replacement transaction $T_R$ is accepted into RAM over an existing transaction $T_O$:

1. Replaceable Signaling: The original transaction $T_O$ must have explicitly signaled BIP 125 replaceability (via nSequence).
2. Descendant Caps: $T_R$ cannot cause the eviction of more than 100 transactions from the mempool.
3. Absolute Fee Increase: The absolute fee of $T_R$ must exceed the absolute fee of $T_O$ and all its descendants combined: $$\text{Fee}(T_R) > \text{Fee}(T_O) + \sum_{D \in \text{Descendants}(T_O)} \text{Fee}(D)$$
4. Relay Fee Coverage: The fee increase must also cover the cost of relaying the new bytes of $T_R$ at the minimum relay feerate (minrelaytxfee): $$\text{Fee}(T_R) - \text{Fee}(T_O) \ge \text{Size}(T_R) \times \text{minrelaytxfee}$$
5. Feerate Escalation: The fee rate of $T_R$ must be strictly higher than the individual fee rate of $T_O$: $$\text{Feerate}(T_R) > \text{Feerate}(T_O)$$

---

⚖️ 3. CPFP vs. RBF: Structural Differences

Metric	Child Pays For Parent (CPFP)	Replace-By-Fee (RBF)
Who Pays?	Recipient (spends unconfirmed output).	Sender (rewrites original input).
Byte Efficiency	Inefficient (requires creating a new $200+\text{ vB}$ transaction, consuming more blockspace).	Highly Efficient (reuses existing inputs and outputs, avoiding extra transaction overhead).
Mempool Impact	Adds a new transaction to RAM.	Replaces and evicts the old transaction, keeping mempool count flat.
BIP Signaling	No signaling required.	Requires nSequence opt-in under BIP 125.

---

🛡️ 4. Security Risks: Zero-Confirmation Merchants

For merchants accepting Zero-Confirmation (0-Conf) payments (instant checkouts before the transaction is mined into a block):

• The Opt-In Trap: If a customer pays with a transaction that signals BIP 125 replaceability, the merchant should never mark the order as paid. The customer can easily broadcast a replacement transaction directing the same inputs back to their own wallet with a higher fee, rendering the merchant's payment extinct.
• Full-RBF Policy: In modern Bitcoin Core releases (v24.0+), nodes can configure mempoolfullrbf=1 in their bitcoin.conf. Under Full-RBF, the node will accept replacements for any unconfirmed transaction, regardless of whether it signaled opt-in via nSequence. This development has made 0-Conf transactions historically insecure, forcing the industry to migrate to the Lightning Network for instant, secure retail payments.