Bitcoin RBF, or Replace-by-Fee, is a way to replace an unconfirmed Bitcoin transaction with a conflicting version that pays more in fees. For a sender who still controls the coins needed to construct a valid replacement, RBF is usually the cleanest way to raise the transaction’s mining incentive without waiting for the original payment to expire from mempools. Under Bitcoin Core 31.0, replacement validation now works with the cluster mempool and a feerate-diagram rule designed to make the mempool economically better after a replacement.
RBF is a mempool and relay policy, not a Bitcoin consensus guarantee. A wallet can fail to expose a fee-bump button, different nodes can see different mempools, and a miner can confirm a valid version before your replacement propagates widely. A safer diagnosis asks who controls the inputs or an unconfirmed output and which fee-bump path is available now.
Key takeaways
- Current Bitcoin Core policy does not require the old BIP125 opt-in signal for a transaction to be replaceable by policy, although wallet interfaces may still describe transactions as “RBF enabled” or “replaceable.”
- RBF is normally a sender-side tool because the replacement spends at least one of the same inputs as the unconfirmed original.
- CPFP, or Child Pays for Parent, can be useful when the recipient or sender controls a spendable unconfirmed output and can create a high-fee child transaction.
- A fee bump must satisfy node policy, not merely choose a fee rate that looks higher on a block explorer.
- Once the original or replacement confirms, fee bumping is finished; RBF does not rewrite a confirmed transaction.
What changed from the old RBF explanation
Many Bitcoin guides still start with the historical BIP125 rule: an input used a sequence number below 0xfffffffe, which signaled that the sender opted into replacement. That description is useful for understanding the history, and BIP125 remains an important specification, but it is no longer the whole operational picture for current Bitcoin Core policy.
Bitcoin Core’s current mempool replacement policy records that full replace-by-fee became the default policy in version 28.0 and that signaling is no longer required. In version 31.0, the cluster-mempool redesign added a further test: the replacement must strictly improve the mempool’s feerate diagram. For a simple transaction in a cluster by itself, the release notes say it is sufficient for the replacement to have a higher absolute fee and a higher feerate than the original. More complex transaction clusters can face additional constraints.
A block explorer’s “RBF: no” label can describe historical signaling without proving that every current relay node will reject a replacement. It also does not mean your wallet can actually construct one. Wallet capability, input control, change outputs, hardware-signing workflow and policy rules all matter.
If the original problem is simply that you chose too low a fee, first review how the Bitcoin mempool and fee market reflect blockspace demand. Fee bumping solves a transaction-specific problem; it does not make congestion disappear.
RBF is a replacement, not an extra payment
A Bitcoin transaction spends specific UTXOs. An RBF replacement conflicts with an unconfirmed transaction by spending one or more of the same inputs. Because both versions cannot ultimately be confirmed as written, nodes that accept the replacement remove the relevant original transaction or transactions from their mempool and keep the replacement if it passes policy.
That makes RBF different from “sending the payment again.” If you create an unrelated second transaction to the same recipient, both transactions can confirm and the recipient may receive twice the intended amount. A proper RBF replacement reuses conflicting inputs and normally preserves the intended payment while changing the fee, usually by reducing change or adjusting inputs and outputs under the wallet’s fee-bump logic.
The current Bitcoin Core policy has several economic constraints. The replacement must pay at least the total absolute fee of the transactions it replaces. It must also add enough fee to cover the bandwidth cost of relaying the replacement at the node’s incremental relay feerate. The current policy documentation gives a default incremental relay feerate of 0.1 sat/vB, although node operators can configure policy. Version 31.0 also requires the replacement to improve the feerate diagram and limits the number of distinct affected clusters.
“One satoshi more” is not a reliable fee-bump strategy. Your wallet should construct a replacement with enough absolute fee and feerate to clear policy and compete for blockspace.
RBF or CPFP? Use this decision tree
The right method depends on control, not on who is more impatient.
| Situation | What you control | First method to consider | Why |
|---|---|---|---|
| You sent the transaction and your wallet offers “bump fee” | Original inputs or wallet change | RBF | Replaces the original without adding a separate child to the package |
| You sent it, but the wallet has no fee-bump function | Keys are yours, but tooling is limited | RBF with compatible wallet workflow, or wait | Key control may permit a replacement even when the original app lacks a button, but importing/signing must be done safely |
| You received an unconfirmed output and can spend it | Recipient output | CPFP | A high-fee child can make the combined parent-plus-child package attractive to miners |
| You sent funds back to yourself and control the change output | Unconfirmed change | RBF first; CPFP can be a fallback | The sender may have both paths available |
| Exchange or custodian sent the transaction | Neither inputs nor private keys | Contact the sender or wait | You cannot create a valid RBF replacement without control of the relevant keys |
| The transaction is already confirmed | No fee-bump action needed | Do nothing | RBF and CPFP address unconfirmed transactions, not confirmed history |
| The transaction disappeared from your wallet’s mempool view | Keys may still be yours | Recheck several explorers/nodes before rebroadcasting | A dropped local transaction can still exist elsewhere, so blindly creating a second payment is unsafe |
This matrix is deliberately control-first. A block explorer can tell you what it sees, but it cannot give you signing authority.
Worked RBF fee example
Suppose an unconfirmed transaction is 140 vB and paid 10 sat/vB. Its fee is:
140 vB × 10 sat/vB = 1,400 sats
Now suppose the wallet constructs a 150 vB replacement and you choose 25 sat/vB. The replacement fee is:
150 vB × 25 sat/vB = 3,750 sats
The replacement pays 3,750 sats in total, exceeding the original transaction’s 1,400-sat fee. Its 2,350-sat fee increase also exceeds the 15 sats required to relay a 150-vB replacement at the default incremental relay feerate of 0.1 sat/vB. The wallet must still satisfy the feerate-diagram and all other applicable policy rules, and the appropriate target feerate depends on current mempool conditions.
Use a current fee estimate and a replacement transaction preview instead of a fixed “add 5 sat/vB” rule. Bitcoin Core 31.0 also changed its estimator so the minimum tracked fee-rate bucket can go below 1 sat/vB when the node has sufficient data, matching its lower default minimum relay policy. That does not mean a low rate will confirm quickly; it means fee estimation can represent quieter markets more precisely.
How to bump a Bitcoin transaction with RBF safely
Start by confirming that the transaction is still unconfirmed. Check your own node if you run one, or compare more than one reputable explorer if the state is ambiguous. Record the transaction ID, outputs, fee and approximate virtual size. Do not assume a wallet’s “pending” label tells you what miners currently see.
Next, use the wallet’s native fee-bump function when available. A well-designed wallet will build a conflicting transaction rather than a duplicate payment, preserve the intended recipient output unless you deliberately change it, and show the new fee before signing. If you use a hardware signer, inspect recipient amount and address on the trusted signing device where supported.
Choose a fee rate based on current conditions and your desired confirmation horizon. A replacement that barely passes relay policy may still sit behind higher-feerate transactions. Conversely, a panicked fee rate can overpay dramatically after congestion has already cleared.
After signing, broadcast the replacement and verify which transaction is now accepted by multiple peers or explorers. It is normal for the original transaction ID to remain visible as a conflicting or replaced transaction in some interfaces. Do not send a third, unrelated payment merely because one explorer updates slowly.
Finally, wait for confirmation and then evaluate finality in the normal way. RBF only changes the unconfirmed stage. Our guide to Bitcoin transaction finality and reorg risk explains why a transaction becomes operationally safer as confirmations accumulate.
When CPFP makes more sense
Child Pays for Parent uses a different economic mechanism. Instead of replacing the low-fee parent, someone who controls one of the parent’s unconfirmed outputs spends it in a child transaction with a sufficiently high fee. A miner evaluating the package can earn enough from parent plus child together to justify including both.
Consider the same 140 vB parent with a 1,400-sat fee. Suppose the child will be 110 vB and you want the combined 250 vB package to average 25 sat/vB. The package needs:
250 vB × 25 sat/vB = 6,250 sats
Because the parent already contributes 1,400 sats, the child would need about 4,850 sats. On 110 vB, that is roughly 44.1 sat/vB for the child itself. The high child rate compensates for the low-fee parent when evaluated as a package.
This calculation is a planning example, not a universal relay guarantee. Package-relay and cluster rules have changed over time, wallet support varies, and a child may have other unconfirmed ancestors. Bitcoin Core 31.0 removed the old CPFP carveout while expanding one-parent-one-child package behavior in other ways. If a wallet offers a tested “accelerate” or CPFP workflow, use its preview rather than manually guessing package policy.
Why an RBF attempt can fail
A fee bump can fail even if the transaction is unconfirmed. The most common operational reason is that the wallet does not control or cannot access the original inputs in a way that its fee-bump workflow understands. Watch-only software, an unavailable hardware signer, a multisig threshold that cannot currently be met, or an exchange withdrawal can all block construction or signing.
Policy can also reject a replacement. The new transaction may not add enough absolute fee, may not pay sufficient incremental relay cost, may fail the feerate-diagram test, or may interact with a transaction cluster in a way the node will not accept. A wallet error that says “insufficient fee” therefore does not necessarily mean the same thing as “network fee is high.” It can mean the replacement itself fails a mempool-policy constraint.
Another failure mode is racing a confirmation. If the original transaction reaches a block while you are preparing or propagating the replacement, the replacement becomes invalid because its inputs have already been spent. This is normal. Once either version confirms, the confirmed transaction wins under consensus.
A final source of confusion is inconsistent mempool visibility. Bitcoin has no single global mempool. Nodes can receive transactions at different times, use different policies, evict transactions under memory pressure, or reconnect after missing a broadcast. Treat a single explorer as an observation point, not as the network’s authoritative pending ledger.
Full RBF changes how to think about zero-confirmation payments
The old mental model that “non-RBF means safe before confirmation” is especially dangerous now. Current Bitcoin Core documentation says signaling is no longer required for replacement policy. More broadly, an unconfirmed transaction has not yet been included in the proof-of-work chain and should not be treated like a confirmed settlement simply because a wallet labels it non-replaceable.
For low-value retail flows, businesses can choose their own risk controls, but the technical distinction remains. The security model changes after a transaction is mined and then strengthened by more blocks. Our guide to Bitcoin confirmations covers that transition from mempool observation to block-depth security.
Unconfirmed transactions will not all be maliciously replaced, but a receiver should not use a historical opt-in flag as a substitute for a settlement policy.
Edge cases worth checking before you act
Exchange withdrawals
If an exchange created the transaction, you usually do not control the inputs. Even if your receiving wallet detects that a higher fee would help, it cannot sign a replacement on behalf of the exchange. CPFP may be possible only if the received output is spendable and your wallet supports spending an unconfirmed incoming output. Otherwise, the correct action is to contact the exchange and wait.
Multisig and collaborative transactions
A replacement may require new signatures from the same signing policy. In a 2-of-3 treasury, for example, one coordinator cannot unilaterally change the transaction if it lacks the required co-signers. Complex collaborative protocols can also face transaction-pinning problems, where another participant uses policy limits to make fee bumping expensive or difficult. Bitcoin Optech’s transaction-pinning reference documents why this matters beyond ordinary single-user payments.
Hardware wallets and PSBT workflows
An offline signer can sign a replacement if the coordinating wallet constructs a valid replacement and the signing policy permits it. Treat the replacement as a new transaction for verification purposes: review destination, amount, change and fee again. Never sign a replacement merely because the computer says it is “the same payment.”
A transaction that appears dropped
If a transaction vanishes from one mempool, do not immediately resend the payment with new inputs. Check whether another node still has it and whether the recipient has already seen it. If the old transaction later propagates or confirms, an unrelated resend can result in two payments. A deliberate conflicting replacement is safer when you control the transaction and intend to supersede it.
Common RBF mistakes
The first mistake is confusing a higher total fee with a higher feerate. A much larger replacement can pay more sats in total yet still be unattractive per vbyte or fail current policy. The second is treating a block explorer’s RBF label as signing authority. It is not. The third is trying to “cancel” a transaction by sending the same amount to yourself without understanding that any successful cancellation replacement must still conflict with the original and pass policy.
Another mistake is overpaying because the user copies a fee rate from an old screenshot, social post or previous congestion event. Fee conditions change block by block. Finally, users sometimes expose seed phrases or private keys to websites that promise to accelerate Bitcoin transactions. Legitimate RBF does not require giving a stranger your seed phrase. If a service asks for it, stop.
BTC-Pulse Take
RBF is best understood as a control-and-policy problem, not a magic accelerator. If you are the sender, control the inputs, and your wallet supports a proper replacement workflow, RBF can efficiently raise the fee of an unconfirmed transaction. If you control only an unconfirmed output, CPFP may be the practical path. If you control neither, no block explorer or “accelerator” can grant you the missing signing authority.
For 2026, do not base the decision on the old opt-in signal alone. Bitcoin Core’s current replacement policy no longer requires that signal, and version 31.0 evaluates replacements inside the cluster-mempool framework. Use current wallet tooling, current fee conditions and explicit transaction control to choose the method.
FAQ
Can I use RBF after a Bitcoin transaction confirms?
No. RBF applies to unconfirmed mempool transactions. Once a transaction is confirmed, a conflicting transaction that spends the same inputs is invalid against the confirmed chain state unless a chain reorganization later removes that confirmation.
Can the recipient use RBF?
Normally the sender uses RBF because the replacement spends the original inputs. A recipient usually does not control those inputs. The recipient may instead be able to use CPFP by spending an unconfirmed output they control with a high-fee child transaction.
Does a transaction need to show “RBF enabled” in 2026?
Not for current Bitcoin Core replacement policy. The current policy documentation states that signaling is no longer required. Wallet interfaces may still expose historical signaling information or use it to decide whether their own fee-bump button is available.
Can RBF change the recipient address?
Technically a conflicting replacement can have different outputs if it remains valid and passes policy. Normal wallet fee-bump workflows are designed to preserve the intended payment and adjust the fee, often from change. Always inspect the replacement before signing.
Does paying a higher fee guarantee the next block?
No. A higher fee can improve the transaction’s relative mining incentive, but blockspace demand, miner selection, package relationships and future transactions all affect confirmation. No fee rate guarantees inclusion in a particular block.
Sources
- Bitcoin Core 31.0 release notes
- Bitcoin Core current mempool replacement policy
- BIP125: Opt-in Full Replace-by-Fee Signaling
- Bitcoin Core 31.0 RPC documentation
- Bitcoin Optech: Replace-by-fee
- Bitcoin Optech: Transaction pinning
This article is educational. Fee-bumping mistakes can cause overpayment, delayed transactions or accidental duplicate payments. Never disclose a seed phrase or private key to a transaction-acceleration website or support account.
