Replace-by-Fee (RBF) Explained

What replacement actually does

• It does not edit the original transaction. Transactions are immutable once signed; there is no 'change the fee' operation.
• It creates a second, conflicting transaction that spends at least one of the same inputs and pays a higher fee.
• Because both spend the same coins, only one can ever confirm. Nodes that accept the replacement drop the original from their mempool.
• Once either version is confirmed, replacement is over. A confirmed transaction cannot be replaced, bumped or cancelled by anyone.

Replacement is not cancellation. Many wallets present a 'cancel' button that is really a replacement sending the funds back to an address you control — which still needs to confirm, and still costs a fee.

Consensus rules versus mempool policy

This distinction is the single most misunderstood point about RBF. Replacement is not defined by Bitcoin's consensus rules. Nothing in the protocol says a node must prefer a higher-paying conflicting transaction.

Replacement is mempool and relay policy: each node decides, for itself, which conflicting transaction it keeps and relays. Miners then mine from what their own node accepted. Because nodes run different software versions and different configurations, there is no single, guaranteed, network-wide answer to whether a replacement will propagate.

Do not assume every node on the network runs the same version or the same policy. A replacement that your node accepts may not reach every miner, which is one of several reasons replacement is never a guarantee of faster confirmation.

When replacement may be available to you

• The transaction is still unconfirmed. Check on a block explorer rather than trusting a wallet label.
• You control the sending wallet — that is, you hold the keys that signed the inputs.
• The wallet exposes a fee bump, increase fee or replace function. Support varies widely; some wallets offer it only for transactions they marked as replaceable when building them.
• The replacement pays enough more than the original to satisfy the relay policy of the nodes it passes through, which requires both a higher total fee and enough extra to cover relaying the new transaction.

When it is not available

• The transaction has confirmed. There is nothing to replace.
• The withdrawal came from an exchange or other custodial service. They signed it, so only they could replace it, and most do not offer that to customers.
• Your wallet has no fee-bump function. There is no safe third-party way to do it for you, and any service offering to is a pattern worth treating as fraudulent.
• The receiving side already treats the original as payment. Replacing a transaction that pays a merchant changes what they receive; that is precisely why zero-confirmation payments are risky for recipients.

How to review a replacement before broadcasting

1. Confirm the transaction is still unconfirmed on an explorer.
2. Open the wallet's own fee-bump or replace function — never a browser tool, a support chat or a downloaded 'accelerator'.
3. Check the new fee rate the wallet proposes against current network conditions, not against the old rate.
4. Check the outputs on the replacement: the recipient address and amount should be exactly what you intended. Some wallets take the extra fee out of the change output, which is normal; taking it out of the recipient's amount is not what you usually want.
5. Broadcast, then track the new transaction ID. The old one may keep appearing on some explorers for a while before it is dropped.

Nothing in this process ever requires your recovery phrase, your private keys, a wallet connection to a website, or a payment to a third party.

RBF versus CPFP: which applies to your situation

Advanced: how replacement policy has evolved

This section is for readers who want the mechanics behind the wallet button. It is not needed to use a fee bump, and it changes over time — treat the Bitcoin Core policy documentation as the current reference rather than any tutorial, including this one.

• Classic mental model: the original transaction had to explicitly signal that it was replaceable, by setting a sequence value below the maximum, as described in BIP 125. Wallets that did not signal could not be bumped, which is why some older wallet interfaces make you decide at send time.
• Full replacement: more recent Bitcoin Core releases apply replacement based on the economics of the conflicting transactions rather than requiring that opt-in signal. Whether a given node behaves this way depends on the version and configuration it runs — which is exactly why signalling and policy are worth distinguishing.
• Fee requirements: replacement policy has always required the replacement to pay more in absolute terms and to cover the bandwidth cost of relaying the new transaction. A higher fee rate alone is not automatically sufficient if the total fee does not also increase enough.
• Descendant and cluster limits: nodes bound how large a group of related unconfirmed transactions they will track. Bitcoin Core has been moving from the older ancestor/descendant count limits towards a cluster-based model, and the specific limits differ by release. This matters mostly to protocols that pre-sign transactions; ordinary payments rarely touch these bounds.
• Package replacement: Bitcoin Core supports only limited package replacement, restricted to simple one-parent-one-child topologies, as set out in its package policy documentation.

None of this changes the practical advice: use your own wallet's replace function, check the fee rate against current conditions, and treat confirmation timing as probabilistic.

Sources

• Bitcoin Core — Mempool replacements policy
• Bitcoin Core — Package mempool accept policy
• BIP 125 — Opt-in full replace-by-fee signalling
• Bitcoin Core — Release notes