Bitcoin Replace-by-Fee (RBF)

What Is Bitcoin Replace-by-Fee (RBF)?

An unconfirmed transaction is still only a candidate for confirmation. RBF uses this interval to submit a conflicting replacement that must satisfy the receiving node’s applicable fee and mempool-policy conditions. Nodes that accept it remove the earlier transaction from their local mempool and retain the replacement instead.

BIP 125 defines opt-in RBF signaling: a transaction signals replaceability when at least one input has an nSequence value below 0xfffffffe, and that status can be inherited from an unconfirmed ancestor. Current Bitcoin Core still recognizes this signaling for opt-in status, but its default full-RBF replacement policy does not require the signal for replacement acceptance. RBF replacement is governed by node mempool and relay policy; BIP 125 signaling is a policy signal rather than a separate consensus-level transaction class.

When Can an Unconfirmed Bitcoin Transaction Be Replaced?

RBF replacement is a mempool process intended for transactions that remain unconfirmed. Creating a replacement also requires access to the private keys or wallet signing authority for the inputs being reused; an explorer can show transaction details but cannot create or authorize a replacement on your behalf.

A transaction may signal BIP 125 directly or inherit opt-in replaceability from an unconfirmed ancestor, but current Bitcoin Core full-RBF policy can accept a replacement without that signal. Propagation is still not guaranteed: each node applies its own mempool configuration and policy, so replacement acceptance and mempool views can differ.

The replacement must conflict with the original by spending at least one of the same inputs. A wallet may fund the higher fee by reducing change or adding another controlled input. Manual replacement is possible only when the sender can construct and sign the conflicting transaction correctly.

How RBF Replacement Works in a Node's Mempool

A sender creates, signs, and broadcasts a replacement transaction. A receiving node checks normal transaction validity first, then applies its mempool replacement policy. Under current Bitcoin Core policy, directly conflicting transactions and their in-mempool descendants can be removed when the replacement satisfies the applicable replacement rules.

Current Bitcoin Core policy limits how many distinct conflicting clusters a replacement may affect and requires the resulting mempool feerate diagram to improve. Earlier BIP 125 policy also restricted new unconfirmed inputs, but that rule has been removed from the current replacement policy.

If accepted, a node relays the replacement to peers according to their policies. Some nodes may retain the original for a time, reject the replacement, or may not receive one version. Miners choose transactions from their own transaction sources and policies, so replacement is an attempt to improve confirmation prospects, not a network-wide command.

What Fee Conditions Matter for a Replacement?

Under current Bitcoin Core policy, the replacement’s absolute fee must be at least the sum of the fees paid by the transactions it replaces. The additional fee must also pay for the replacement’s bandwidth at the node’s incremental relay feerate. A small fee increase can therefore be insufficient.

Feerate, measured in satoshis per virtual byte, matters because block space is limited. A larger replacement may need a substantially greater absolute fee to achieve a competitive feerate. If you add another input to fund the increase, the transaction grows, which can reduce the benefit unless the added fee rises accordingly.

There is no universal fee amount that guarantees the next block or any particular confirmation time. Fee conditions determine whether a node may accept the replacement; competition with other transactions and miner selection determine whether it is confirmed. Use a current fee estimate as context, then let your wallet calculate and display the final fee before signing.

How to Check Whether Your Wallet Can Bump the Fee

Start with the wallet that controls the transaction’s inputs and check whether it provides a fee-bump or replacement function. Wallet capabilities vary. To construct a replacement, the wallet needs signing authority for the reused inputs and a valid way to increase the fee, such as reducing an output amount or, where appropriate, adding a controlled input.

Use UnlockPool’s Bitcoin Transaction Checker at /bitcoin-transaction-checker to review the available confirmation status, fee, inputs, and outputs. To inspect BIP 125 opt-in signaling, use a wallet or decoder that specifically displays input nSequence values; a value below 0xfffffffe is an opt-in signal. Current Bitcoin Core replacement policy does not require that signal.

Do not send an unrelated second transaction merely because the first seems delayed. An RBF replacement must deliberately conflict with the original, pay a higher fee, and satisfy applicable relay policy. If the original is already confirmed, RBF no longer applies.

RBF vs Canceling a Bitcoin Transaction

RBF is not a protocol-level cancellation command. It creates a replacement candidate that competes with the original while both are unconfirmed. A sender may sometimes make the replacement pay back to an address they control, which is commonly described as “canceling,” but it is still a new transaction that must be accepted by nodes and confirmed by a miner.

An unconfirmed payment is not irreversible merely because it appears in an explorer. RBF signaling can make replacement intent explicit, but conflicting transactions, mempool eviction, relay differences, and miner selection can still affect an unconfirmed transaction.

For time-sensitive payments, confirmation requirements should reflect transaction risk. RBF itself is not evidence of fraud; it is commonly used to correct an inadequate fee.

RBF vs CPFP: How Are They Different?

RBF changes the parent transaction itself by spending the same inputs again in a higher-fee replacement. It generally requires the sender’s signing authority and a transaction that is eligible for replacement under the receiving nodes’ policies. The new transaction can modify outputs, provided it remains valid and the wallet can authorize it.

Child-Pays-for-Parent, or CPFP, leaves the parent transaction unchanged. It creates a child transaction that spends one of the parent’s unconfirmed outputs and pays a fee high enough that miners may consider the combined parent-and-child package attractive. CPFP can be useful when the sender cannot create a suitable replacement or when the recipient controls a spendable output from the parent.

RBF and CPFP are not interchangeable. CPFP may be available to whoever can authorize spending a suitable unconfirmed parent output, while constructing an RBF replacement requires authorization for the inputs reused by the replacement.

What Happens to the Original Transaction After a Replacement?

On nodes that accept the replacement, the original transaction is removed from their local mempool along with any affected descendants. The replacement takes its place as the preferred candidate because it spends the same input or inputs. This does not erase the original transaction from records held by wallets, explorers, or nodes that saw it.

If the replacement confirms first, the original becomes invalid because its inputs are now spent by the confirmed replacement. If the original confirms first, the replacement becomes invalid for the same reason. Until a block settles the conflict, different nodes can report different local mempool states.

Because mempools are local, an explorer reflects only the transactions and policy view available to its infrastructure. Different node views can therefore differ before confirmation. Confirmation in the blockchain, rather than an individual mempool display, resolves the outcome.

When RBF Will Not Help

RBF will not help after confirmation, without the required signing authority, or when a valid policy-acceptable replacement cannot be built. An attempt can also fail because the fee increase is insufficient, the replacement violates node policy, or peers do not relay it.

A transaction can remain unconfirmed for reasons beyond its fee. It may be below local relay thresholds, depend on an unconfirmed ancestor, conflict with another transaction, or be absent from the mempool you are checking. Review the transaction’s status before assuming it is simply stuck. UnlockPool’s guides at /learn/stuck-bitcoin-transaction and /learn/unconfirmed-bitcoin-transaction provide a separate diagnostic path.

If RBF is unavailable, CPFP may be an alternative when a controllable unconfirmed output exists. Otherwise, waiting may be necessary. Repeatedly broadcasting poorly formed conflicts does not improve confirmation.

Verify the Transaction and Current Mempool Conditions with UnlockPool

Use UnlockPool’s Bitcoin Transaction Checker at /bitcoin-transaction-checker to inspect the transaction’s confirmations, fee details, inputs, and outputs. For the broader fee environment, the Bitcoin Fee Estimator at /bitcoin-fee-estimator presents current estimates, while the Bitcoin Mempool Tracker at /bitcoin-mempool shows live mempool conditions.

These tools provide node-local observations. Bitcoin nodes can differ in transaction inventory, policy, and propagation, so mempool views can differ. Compare explorer data with your own wallet before approving a replacement, especially when the change amount is modified.

For a practical explanation of timing after a transaction is accepted for mining, see the Bitcoin Confirmation Time Guide at /learn/bitcoin-confirmation-time. The important distinction is simple: RBF can be considered only while the transaction remains unconfirmed, and it is a fee-bumping replacement process rather than a reversal of a completed Bitcoin payment.

Frequently Asked Questions

Summary

RBF can revise the fee of an eligible unconfirmed transaction when the sender can sign a valid replacement. Check confirmation status first, use the wallet’s fee-bump feature where available, and judge the outcome by blockchain confirmation rather than one node’s mempool view.