Guide
What Is RBF (Replace-by-Fee)? Rescuing a Stuck Bitcoin Transaction
Replace-by-fee (RBF) lets you replace an unconfirmed transaction with a different one that spends the same coins and pays a higher fee. When a payment is stuck because the fee was set too low, RBF is how you fix it — by overwriting it rather than sending again.
要点
RBF is a tool for senders. For receivers it means one thing: a zero-confirmation payment can still be rewritten. Since Bitcoin Core 28.0 (October 2024) full RBF is the default, so replaceability no longer depends on the sender's settings. Nothing here is investment advice.
Why transactions get stuck
A broadcast transaction sits unconfirmed in each node's mempool, and miners generally fill blocks starting from the highest feerate (sat/vB). Pick a low feerate during congestion and your transaction waits at the back of the queue, sometimes for hours. See how Bitcoin fees work and what to do when a transaction won't confirm.
How RBF works
RBF is not a cancel button. You broadcast a new transaction spending the same inputs, with a higher fee. Because no node will accept two transactions spending the same coins, the qualifying replacement evicts the original from the mempool, and only the new one ever gets mined.
To qualify, a replacement must pay both:
- a higher feerate (BTC per virtual byte), and
- a higher absolute fee (total BTC paid).
Meeting only one of the two is not enough.
Opt-in RBF versus full RBF
Opt-in RBF (BIP125), implemented in Bitcoin Core 0.12.0, required the sender to flag a transaction as replaceable in advance. Transactions without the signal were, by policy, not replaceable.
Full RBF allows replacement whether or not a transaction signals BIP125 replaceability. In Bitcoin Core, the default for -mempoolfullrbf was changed from 0 to 1 in version 28.0 (October 2024), and a later change removed the configuration option entirely (Bitcoin Core #30592).
The practical takeaway is a single sentence: you can no longer assume a transaction is safe from replacement just because it did not signal RBF (as of 2026-08-09).
What receivers need to know
This is the consequence that matters most.
- A zero-confirmation payment is not settled. The sender can replace it with a higher-fee transaction that pays someone else entirely.
- Hand over goods or start service only after at least one confirmation, and wait for more as the amount grows.
- The confirmation thresholds exchanges and payment processors publish exist partly for this reason.
See what a confirmation is and what double spending is.
RBF or CPFP?
There is a second way to add fee after the fact: CPFP (Child Pays For Parent).
| RBF | CPFP | |
|---|---|---|
| Who can use it | The sender, replacing their own transaction | The receiver can use it too |
| What you do | Rebroadcast the same inputs with a higher fee | Spend the unconfirmed output in a high-fee "child" |
| How it helps | The old transaction is evicted; the new one confirms | Parent and child are mined together, lifting the parent |
Your own outgoing payment is stuck → RBF. You want an incoming unconfirmed payment to settle faster → CPFP. Wallet support varies, so it is worth checking whether yours has a "bump fee" option before you need it.
Practical cautions
- The replacement must spend the same inputs as the original. A wallet's bump-fee feature handles this for you.
- The extra fee comes out of your funds, usually from the change output.
- Each replacement costs more. Sometimes simply waiting for congestion to clear is the cheaper option — judge it from the current mempool.
- If you sent to the wrong address, RBF can sometimes redirect the payment while it is still unconfirmed. After confirmation it is gone — see sending to the wrong address.
Sources
FAQ
- What is replace-by-fee (RBF)?
- It replaces an unconfirmed transaction with a different one that spends the same inputs and pays more. The replacement must pay both a higher feerate per virtual byte and a higher absolute fee than the transaction it replaces.
- Does RBF require the sender to signal it?
- Not any more. BIP125 opt-in RBF required a signal, but Bitcoin Core 28.0 (October 2024) changed the -mempoolfullrbf default from 0 to 1, making full RBF the default, and a later change removed the option entirely.
- Is it safe to accept a zero-confirmation payment?
- No. With full RBF as the default, a sender can replace an unconfirmed payment with a higher-fee transaction paying someone else. Wait for at least one confirmation before releasing goods, and more for larger amounts.
- When should I use CPFP instead of RBF?
- Use RBF when your own outgoing transaction is stuck, since only the sender can replace it. Use CPFP when you are waiting on an incoming unconfirmed payment: spending its output in a high-fee child transaction pulls the parent into a block with it.
This article is informational only and is not financial, investment, or trading advice. Prices are reference snapshots and may be outdated. Always do your own research.