Replace-By-Fee (RBF) Mechanics

Replace-By-Fee (RBF) is a protocol feature that allows a user to "bump" the fee of a transaction that is stuck in the mempool due to low fees. This is enabled via the Sequence field.

1. Signaling RBF (BIP 125)

To signal that a transaction is replaceable, at least one input in the transaction must have a sequence number less than 0xffffffff - 1 (specifically 0xfffffffd or lower).

• Opt-in RBF: This signals to miners and nodes: "I might send a replacement for this transaction with a higher fee."

2. The Replacement Rules

For a new transaction to replace an existing one in the mempool, it must satisfy several criteria:

1. Higher Fee: The new transaction must pay a higher absolute fee than the one it replaces.

2. Higher Feerate: The new transaction must also have a higher fee per byte (sat/vB).

3. Conflict: The new transaction must spend at least one of the same inputs as the original.

4. No New Unconfirmed Parents: To prevent spam, the replacement cannot introduce too many new unconfirmed dependencies.

3. Why Use RBF?

• Congestion: If the network becomes busy, your 1 sat/vB transaction might never confirm. RBF lets you update it to 10 sat/vB.

• Cancellation: While not a formal "cancel," you can use RBF to spend the same inputs back to yourself with a much higher fee, effectively "canceling" the original payment.

4. Security Considerations

Merchants who accept "0-confirmation" payments (unconfirmed transactions) must check if the transaction signals RBF.

• If RBF is enabled: The transaction could be replaced by the sender at any moment.

• If RBF is disabled: (Sequence = 0xffffffff), it is much harder (though not impossible) to replace the transaction.

Signaling	Sequence Value	Status
Max / Final	0xffffffff	RBF Disabled
Opt-in RBF	0xfffffffd	RBF Enabled
BIP 68 lock	0x00000001	RBF Enabled + Timelock

In the next section, we will look at Relative Timelocks (BIP 68).