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

️ 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.