Replace-By-Fee (RBF)

The primary function of RBF is to increase the fee of a stuck transaction. This is done by broadcasting a new transaction that spends the same inputs but includes a higher fee, making it more attractive for miners to include in the next block.

• Use Case: A user broadcasts a transaction with a low fee, and network congestion causes delays. They can use RBF to 'bump' the fee to outbid competing transactions.

There are two main RBF policies. Full RBF (BIP 125) is the standard implementation, allowing any unconfirmed transaction to be replaced if it meets specific signaling and fee increase rules. First-Seen-Safe (FSS) RBF is a more restrictive variant that only allows replacement if all outputs are increased, preventing certain types of fraud.

• Key Rule: Full RBF requires the new fee to be higher than the sum of the original fee and the fees of all transactions it depends on (ancestor fee).

A transaction must explicitly signal that it is replaceable. This is done by setting the nSequence field of its inputs to a value less than 0xffffffff - 1. This opt-in design prevents accidental or malicious replacements of transactions that were intended to be final.

• Developer Note: Wallets must construct transactions with the correct nSequence values to enable RBF functionality.

RBF provides a conflict resolution mechanism for the mempool. When a higher-fee replacement is valid, nodes and miners will evict the original, lower-fee transaction. This creates a competitive fee market for block space and allows users to correct mistakes without waiting for a timeout.

• Example: It can also be used to correct a wrong destination address by creating a new transaction that returns funds to oneself.

Contrary to some misconceptions, RBF with proper wallet implementation enhances security against double-spend attacks. By allowing a legitimate sender to replace their own transaction, it reduces the incentive for a malicious receiver to attempt a double-spend via a conflicting transaction, as the sender can always outbid them.

RBF is a critical tool for mempool management at the network level. It helps clear low-fee transactions during congestion, making the mempool a more efficient queue. Miners can prioritize the highest-paying transactions, and users have direct control over their confirmation priority without relying on Child-Pays-For-Parent (CPFP).

RBF works by broadcasting a new transaction that spends the same inputs as a prior, unconfirmed transaction but with a higher fee. Miners are incentivized to include the newer, higher-fee version in a block. Key requirements include:

• The new transaction must pay a higher fee rate (sat/vB).
• It must include all original outputs, though it can add new ones.
• It must be signaled as replaceable (via nSequence or full-RBF policy).

There are two primary implementations in the Bitcoin network:

• Opt-In RBF (BIP 125): The standard. Transactions must explicitly signal replaceability by setting an nSequence number less than 0xffffffff-1. This provides explicit consent.
• Full RBF: A more permissive node policy (not a consensus rule) where some nodes will replace any unconfirmed transaction with a higher-fee version, regardless of signaling. This is controversial and not universally adopted.

RBF addresses critical wallet and user experience issues:

• Fee Acceleration: Bumping a stuck transaction during network congestion.
• Error Correction: Fixing mistakes like an incorrect recipient address or an underpaid fee before confirmation.
• CPFP Alternative: When the receiver cannot perform Child-Pays-For-Parent, the sender can use RBF directly.
• Batching Optimization: Replacing a set of individual transactions with a single, more efficient batched transaction.

While useful, RBF introduces specific risks that merchants and services must manage:

• Zero-Confirmation Risk: Accepting unconfirmed RBF-enabled transactions is unsafe, as the sender can double-spend by replacing it with a transaction sending funds elsewhere.
• Pinpointing Attacks: A malicious actor could broadcast a low-fee transaction, get a service to accept it, then replace it to steal goods/services.
• Mempool Policies: Nodes have different RBF policies, leading to inconsistent propagation and potential network partitioning.

Support for RBF is widespread but not uniform across the ecosystem:

• Wallets: Most major wallets (Electrum, BlueWallet, Sparrow) support BIP 125 Opt-In RBF, often with a toggle during transaction creation.
• Nodes: Bitcoin Core has configurable RBF policies (mempoolfullrbf). Other implementations like Bitcoin Knots may have different defaults.
• Explorers & Services: Block explorers (mempool.space) visually flag RBF-enabled transactions. Payment processors and exchanges often have policies to delay credit for such transactions.

RBF is one tool in the transaction management toolkit. Understand its alternatives:

• Child-Pays-For-Parent (CPFP): The receiver of an unconfirmed output creates a new, high-fee transaction spending it, incentivizing miners to confirm both.
• Fee Bumping (PSBT): Partially Signed Bitcoin Transactions enable collaborative fee increases, often used with hardware wallets.
• Transaction Malleability: RBF is distinct from malleability fixes (SegWit); it's a deliberate replacement, not a third-party signature modification.

The general practice of increasing the fee of a broadcasted transaction to improve its confirmation priority. RBF and CPFP are the two primary fee bumping techniques.

• RBF: Replaces the original transaction entirely.
• CPFP: Creates a new, dependent transaction.
• Goal: Overcome initial fee underestimation during network congestion.

The memory pool where all valid, unconfirmed transactions wait to be included in a block. RBF transactions compete within the mempool based on their fee rate (sat/vB).

• Function: Nodes maintain their own view of pending transactions.
• RBF Interaction: A replacement transaction must meet specific rules (e.g., higher fee, all original signers) to be accepted into the mempool, replacing its predecessor.

The specific, widely adopted implementation of RBF defined in BIP 125. It requires transactions to signal replaceability explicitly by setting the nSequence field to a value below 0xffffffff.

• Key Rule: Only transactions that opt-in can be replaced.
• Security: Prevents unexpected replacement of transactions that receivers assumed were final, preserving the zero-confirmation risk model for non-signaling transactions.

The malicious act of spending the same UTXO twice. While RBF can be used to double spend, its opt-in requirement and transparent replacement mechanism make it a coordinated replacement, not a covert attack.

• Contrast: A malicious double spend typically broadcasts two conflicting transactions to different parts of the network simultaneously.
• RBF vs. Double Spend: RBF provides a legitimate, rule-based replacement path, making the intent clear to all network participants.

A controversial policy proposal where any unconfirmed transaction could be replaced, not just those that opted in. This would eliminate the concept of zero-confirmation trust entirely.

• Status: Not implemented in Bitcoin Core by default. Some nodes run with this policy.
• Debate: Proponents argue for economic efficiency; opponents argue it harms fast payment use cases by removing all pre-confirmation security assumptions.