Bitcoin replace-by-fee (RBF) lets a sender replace an unconfirmed transaction with another transaction that spends at least some of the same inputs and offers a higher fee under the receiving node’s policy.
The replacement is a new transaction, with its own transaction ID. It does not edit a transaction already recorded in a block, and broadcasting it does not guarantee that a miner will include it next.
There are three separate questions: what your wallet can construct, what nodes will accept and relay, and which transaction gets confirmed. Mixing them together is why an “RBF enabled” label can be misleading.
A pending transaction is not a settled payment
Before confirmation, a transaction may be held in nodes’ mempools. Those are collections of transactions waiting for possible inclusion in blocks, not one global queue with a guaranteed position.
A replacement conflicts with the original by spending shared inputs. A node that accepts the replacement updates its mempool according to its replacement policy. The original and replacement are not two independent payments that can both spend the same input in the same accepted chain history.
The recipient still needs to check what actually confirms. A screenshot of an unconfirmed transaction is not evidence that a particular version is final.
BIP 125, assigned 4 December 2015, explicitly discusses how receiving wallets should treat replaceable unconfirmed transactions. It is a historical opt-in policy specification, not a current guarantee about every wallet or node.
Opt-in signaling and full-RBF are different
Under BIP 125’s opt-in approach, a transaction signals replaceability through input sequence values. Replaceability can also be inherited from an unconfirmed ancestor that signals it.
The document describes the initial implementation expected in Bitcoin Core 0.12.0, including replacement rules. Those details explain the history; they should not be copied wholesale into a claim about all present-day policy.
Bitcoin Core’s 29.0 release notes, published 14 April 2025, describe a later change. Full-RBF had become the default in version 28.0, and version 29.0 removed the option for disabling it.
Full-RBF policy allows replacement without requiring the original transaction’s opt-in signal. It is still node policy, not a promise that every wallet will expose a convenient fee-bump button or that every service will treat pending payments alike.
This guide uses those named versions as documentation points. It does not describe version 29.0 as a new October 2026 release or assert that it is the latest Bitcoin Core version.
What a wallet fee bump actually changes
A wallet must be able to create and authorise the replacement. An exchange withdrawal or other custodial payment may be controlled by the service, rather than by a wallet holding your keys.
Bitcoin Core’s version 29.0 bumpfee documentation says that the original opt-in-RBF transaction must be in the wallet. Its documented operation can reduce change or add inputs to pay the additional fee, and includes all original inputs in the replacement.
The same documentation says the command fails if a wallet or mempool transaction spends one of the original transaction’s outputs. That illustrates why a node’s support for replacement does not make every pending transaction eligible for this particular wallet operation.
Check your wallet’s own official instructions before using a fee-bump feature. Establish which transaction it is replacing, whether recipient amounts remain as intended and what total fee the new transaction will pay.
Our crypto wallet explainer covers the separate question of who controls the keys needed to authorise transactions.
Fee rate and total fee need separate checks
A fee rate describes the fee relative to transaction size. A total fee is the amount paid by the transaction. A replacement can have a different size if it adds inputs or changes outputs.
For an illustrative transaction of 200 virtual bytes, a rate of 3 satoshis per virtual byte corresponds to 600 satoshis. At the same size, 10 satoshis per virtual byte corresponds to 2,000 satoshis.
Those figures are arithmetic examples, not live recommendations or a guarantee that the replacement meets a node’s rules. Actual transaction size, applicable replacement policy and the transactions affected by replacement matter.
Version 29.0’s documentation identifies its fee-rate input in satoshis per virtual byte and notes that older versions before 0.21 used a different unit. That is a reason to read the documentation for the software you are actually using before interpreting a number.
Do not confuse a provider’s service charge with the transaction’s miner fee. If a custodial service offers a paid acceleration option, verify its own terms rather than assuming it is the same operation described by Bitcoin Core.
Keep the replacement transaction ID
The documented bumpfee result includes a new transaction ID, the original fee, the new fee and an errors field.
If you are reconciling a payment, keep the old and new IDs together. A customer or recipient who continues checking only the original ID may see a transaction that no longer represents the version eventually confirmed.
For a business workflow, record the intended recipient and amount alongside those IDs. A fee-bump action should not become an excuse to stop checking the transaction’s outputs.
A replacement can be received by one node without having been observed everywhere. Confirmation is still a separate event. Your wallet’s status should be read as evidence of what it reports, rather than a universal view of all nodes.
A pending payment deserves a precise question
Before taking action, establish:
- Is the transaction still unconfirmed?
- Does your wallet control and support a replacement for it?
- Does the wallet document restrictions involving change, descendants or available inputs?
- What fee and outputs will the replacement use?
- What new ID should the recipient follow?
- Which version actually becomes confirmed?
If the payment was sent by a custodial provider, ask that provider about the specific withdrawal. Importing an address into another wallet does not create the authority to replace a transaction sent with someone else’s keys.
If the payment is already confirmed, RBF is not a tool for rewriting it. If the problem is a wrong recipient rather than a low fee, do not present fee bumping as a guaranteed recovery or cancellation service.
Sources and version stamp
Checked 9 October 2026. Primary sources: BIP 125, assigned 4 December 2015; Bitcoin Core 29.0 release notes, 14 April 2025; and bumpfee RPC documentation exported from version 29.0. The article explains documented behaviour and historical changes; it does not claim hands-on testing or current network-wide adoption statistics.
