Replace-by-Fee (RBF) Signaling

RBF is an opt-in feature. A transaction must explicitly signal its replaceability by setting the nSequence field of at least one input to a value less than 0xffffffff - 1. This prevents accidental or malicious replacements of transactions that do not intend to allow it. The most common signaling value is nSequence = 0xfffffffd.

For a replacement to be accepted by the network, it must follow the strict rules defined in BIP 125:

• The new transaction must pay a higher fee rate than the original.
• The new transaction cannot add any new inputs (except from the original sender).
• The new transaction cannot remove any outputs that paid the original recipient.
• The replacement must be received by a node before the original transaction is mined.
• The original transaction must not be in any block.

The primary use case is fee bumping. If a low-fee transaction is stuck in the mempool, the sender can create a new version with a higher fee, using RBF signaling to replace it. This is crucial during periods of network congestion. Methods include:

• Direct Replacement: Increasing the fee on the original outputs.
• Child-Pays-For-Parent (CPFP): An alternative where a new transaction spends the output of the stuck one, but RBF is often simpler for the sender.

RBF is a mempool policy, not a consensus rule. Full nodes enforce the BIP 125 rules for transactions they relay and consider for mining, but miners are free to mine either the original or the replacement transaction. This means a replacement is not guaranteed; a miner could still mine the lower-fee original. However, rational miners are incentivized to select the higher-fee version.

RBF introduces a double-spend risk for zero-confirmation transactions. A merchant accepting an RBF-signaled payment with 0 confirmations risks the sender replacing it with a transaction that pays the coins back to themselves. Therefore, services must either:

• Wait for at least 1 confirmation for RBF-signaled transactions.
• Implement detection and reject RBF-signaled transactions for instant payments.
• Use protocols like RBF Double-Spend Proofs to detect replacement attempts.

There are two conceptual models:

• Opt-In RBF (BIP 125): The current standard. Only transactions explicitly signaled can be replaced.
• Full RBF: A more permissive (and controversial) policy where any unconfirmed transaction could be replaced by a higher-fee version, regardless of signaling. Some node implementations (e.g., Bitcoin Core) allow enabling Full RBF as a non-default configuration option, arguing it simplifies fee estimation and mempool dynamics.

The standard method for initiating a replaceable transaction. A sender must explicitly signal that a transaction is replaceable by setting the nSequence field to a value less than 0xffffffff. This opt-in requirement prevents accidental or malicious replacements of transactions that were intended to be final. Wallets like Electrum and Bitcoin Core implement this signaling, allowing users to mark a transaction as replaceable during its creation.

A more permissive network policy where nodes accept transaction replacements even without the opt-in signal. This is a contentious topic, as it changes the default security model. Bitcoin Core has a configurable option (mempoolfullrbf=1) to enable this policy. Proponents argue it improves fee market efficiency, while critics contend it weakens zero-confirmation security for merchants. Its adoption is not universal across the network.

RBF is one of several methods to increase a transaction's fee post-broadcast. Key alternatives include:

• Child-Pays-For-Parent (CPFP): A new transaction spending an output from the stuck transaction, with a high enough fee to encourage miners to confirm both.
• Transaction Accelerators: Services offered by some mining pools or exchanges for a fee. RBF is often the most direct method, as it modifies the original transaction directly.

Adoption varies significantly across the ecosystem. Custodial wallets and exchanges often disable RBF for user simplicity and to prevent fraud, as replacements can complicate deposit tracking. Non-custodial wallets like Electrum, Sparrow, and BlueWallet offer robust RBF support, giving users control over fee management. This creates a user experience divide where RBF is a power-user feature rather than a universal default.

RBF introduces a controlled form of double-spend risk for zero-confirmation transactions. A merchant accepting an unconfirmed payment must check if the transaction is signaled as replaceable. If it is, the payment is not secure until confirmed. This is a critical consideration for Point-of-Sale systems. The protocol requires the replacement transaction to pay a higher fee and have all the same original inputs, limiting but not eliminating the risk.

RBF interacts directly with mempool economics. When network congestion is high, users can outbid others by replacing their low-fee transactions. This creates a more efficient fee auction within the mempool. Miners are economically incentivized to accept RBF replacements as they collect the higher fee. The feature helps clear the mempool of stale, low-fee transactions, optimizing block space allocation for the highest bidders.

RBF provides a formal, opt-in mechanism for transaction replacement, which paradoxically helps prevent double-spend attacks. By signaling intent to replace a transaction, the sender provides a clear, mempool-visible alternative, making malicious double-spends (where a sender secretly tries to spend the same UTXO twice) more difficult to execute covertly. This increases network transparency and security for accepting zero-confirmation transactions.

RBF directly influences Bitcoin's fee auction model. It allows users to participate in fee bidding for block space after a transaction is broadcast. This creates a more efficient market where users can adjust their bids based on changing network congestion, but it can also lead to fee inflation as users compete to get their transactions confirmed in the next block.

Full nodes enforce strict mempool policies for RBF. Key rules include:

• The new transaction must pay a higher fee rate.
• It must pay the absolute fee difference to all original recipients.
• It cannot add new outputs (with some BIP125 exceptions). Without these rules, RBF could enable transaction pinning attacks, where an attacker broadcasts a low-fee transaction to lock up UTXOs, preventing the legitimate owner from spending them.

For merchants accepting fast payments, RBF complicates the security of zero-confirmation transactions. A transaction with RBF signaling is explicitly mutable, making it risky to accept before confirmation. Merchants must implement policies to either:

• Wait for 1+ confirmations for RBF-enabled transactions.
• Reject RBF-signaling transactions outright.
• Use specialized monitoring for double-spend attempts.

Wallet developers face key design decisions:

• Default RBF: Whether to enable RBF signaling by default (common in privacy-focused wallets).
• Fee Bumping Methods: Offering Child-Pays-for-Parent (CPFP) as a safer, collaborative alternative for recipients.
• User Interface: Clearly warning users when they are creating a replaceable transaction to prevent unintended security lapses.