Replace-By-Fee re-signs the same payment with a higher fee, and the new version supersedes the old one across the network. Since Bitcoin Core 28 shipped full RBF, every unconfirmed transaction is replaceable regardless of any flag, so the only remaining question is whether your wallet exposes the button.
If you sent a transaction and it is priced too low, this is the fix. It is faster than waiting, dramatically cheaper than any accelerator, and it works on every miner rather than only the ones somebody has an arrangement with.
It also has the most outdated body of advice attached to it of any topic in Bitcoin, which is why this guide spends its first section on what changed.
What RBF actually does
A replacement is a new transaction that spends the same inputs as the original and pays a higher fee. Because both cannot exist in a block, nodes accept the better paying one and discard the other.
Two things follow from that, and both matter in practice. Your transaction ID changes, because the transaction is different. And the replacement can send the coins somewhere else entirely, which is how people effectively cancel a payment.
What it is not
It is not a way to reverse a confirmed transaction. Once a transaction is in a block it is final and nothing on this page applies. Replacement only works while the transaction is unconfirmed.
What full RBF changed, and why old guides are wrong
The original design, BIP 125, made replacement opt-in. A transaction had to signal its willingness by setting a sequence number, and wallets had a checkbox for it. If you forgot to tick it, you could not replace the transaction later.
That is what nearly every guide on the web still describes, and it stopped being true. Bitcoin Core 28 made full RBF the default, and Core 29 removed the option to turn it off. Every unconfirmed transaction on the network is now replaceable, whether it signalled anything or not.
The practical difference
You no longer need to check whether your transaction was flagged as replaceable. It is. If a guide tells you to look for an RBF badge on a block explorer before deciding whether you can bump, that guide predates Core 28 and is describing rules that no longer apply.
The only thing standing between you and a replacement now is your wallet's interface.
Who can use it, and who cannot
RBF is a sender-side tool. Replacing a transaction means signing a new one with the same inputs, and only the owner of those inputs can do that.
- You sent it from your own wallet. RBF is available to you.
- Somebody sent it to you. You cannot replace it. Use CPFP instead.
- It came out of an exchange. The exchange signed it, so only they can replace it. The exchange guide covers your options.
What a bump actually costs
The cost is the difference between the total fee you want and the total fee you already paid, plus a small amount to satisfy the incremental relay requirement. Nodes will not accept a replacement that pays the same or barely more, because that would let anyone spam the network with free rewrites.
| Transaction size | Original at 0.2 sat/vB | Bumped to 1.5 sat/vB | You pay extra |
|---|---|---|---|
| 141 vB, one input one output | 28 sats | 212 sats | 184 sats |
| 250 vB, typical payment | 50 sats | 375 sats | 325 sats |
| 500 vB, several inputs | 100 sats | 750 sats | 650 sats |
| 1,000 vB, consolidation | 200 sats | 1,500 sats | 1,300 sats |
At current prices the right hand column is a fraction of a dollar in every row. Compare that against the quotes we measured from paid accelerators, which ran three to seventeen times the actual shortfall.
Get your exact number first
We calculate the real shortfall for your transaction in satoshis, so you know what to set rather than guessing.
Doing it in each wallet
Electrum
Right click the pending transaction in the history list and choose Increase fee. Electrum offers a target fee rate and shows the new total. Confirm and it broadcasts the replacement immediately. Electrum handles the incremental relay requirement for you.
Sparrow
Open the Transactions tab, right click the unconfirmed entry, and select Increase Fee. Sparrow shows the original and replacement side by side with both fee rates, which makes it the clearest of the desktop wallets for this. Sign and broadcast.
Bitcoin Core
In the GUI, right click the transaction and choose Increase transaction fee. From the console, bumpfee <txid> does the same, and bumpfee <txid> '{"fee_rate": 2}' sets an explicit rate in sat/vB. If your wallet is watch-only or on a hardware device, use psbtbumpfee instead and sign the result separately.
BlueWallet
Tap the pending transaction, then Bump fee. It presents a new fee estimate and rebroadcasts on confirmation. Mobile wallets vary in how much control they give over the exact rate, so check the resulting fee rate before confirming.
Trezor Suite
Open the transaction detail and use Bump fee. Suite recalculates and asks you to confirm on the device. Straightforward, though it gives less manual control over the target rate than the desktop wallets.
Ledger Live
Open the operation details and use Speed up. It builds a replacement for device confirmation. Ledger Live supports RBF but not CPFP, so if you are the receiver of a stuck payment rather than the sender, Ledger Live cannot help and you will need another route.
| Wallet | RBF | Set exact rate | CPFP too |
|---|---|---|---|
| Electrum | Yes | Yes | Yes |
| Sparrow | Yes | Yes | Yes |
| Bitcoin Core | Yes | Yes | Yes |
| BlueWallet | Yes | Limited | Yes |
| Trezor Suite | Yes | Limited | Partial |
| Ledger Live | Yes | Limited | No |
| Exodus | Partial | No | No |
| Exchange withdrawal | No | No | Receiver only |
How high should you go
Aim just above the rate the next block is currently clearing, not dramatically above it. Paying ten times the going rate does not get you mined ten times sooner. Once you are above the clearing rate you are in the next block or two, and everything beyond that is a donation.
The rate moves through the day, so check it at the moment you bump rather than relying on a number you saw yesterday.
Using a replacement to cancel a payment
Because the replacement can pay different outputs, you can send the coins back to an address you control instead of to the original recipient. The higher fee wins, the original is discarded, and the payment effectively never happened.
Do not treat this as reliable cancellation
It only works while the transaction is unconfirmed, and a miner could include the original at any moment. Never rely on being able to reverse a payment you have already told somebody about. Treat it as a way to recover from a mistake quickly, not as an undo button.
When RBF will not work
- The transaction already confirmed. Nothing to replace.
- You do not control the inputs. Use CPFP if you received the payment.
- Your wallet does not expose it. Some custodial and simplified wallets omit the feature entirely.
- The replacement does not pay enough more. Nodes require a genuine increase, not a token one.
- The transaction is part of a large cluster. Since Core 31 the mempool limits connected groups to 64 transactions, and a replacement that would break those limits is rejected.
RBF or CPFP, which one
| Situation | Use | Why |
|---|---|---|
| You sent it, wallet supports bumping | RBF | Cheapest, one transaction instead of two |
| You received it | CPFP | You cannot re-sign somebody else's transaction |
| You sent it but have a change output | Either | RBF is cheaper if available |
| An unconfirmed parent is the real problem | CPFP | Lifts the whole package rather than one part |
| It came from an exchange | CPFP, or wait | Only the exchange can replace its own transaction |
The bottom line
If you sent it and your wallet has the button, RBF is almost always the correct answer. It costs a few hundred satoshis, it works against every miner on the network, and it takes under a minute. Ignore any guide telling you to check whether your transaction opted in, because since Core 28 they all do.
Know the number before you bump
Paste your transaction ID and we show the effective rate, the clearing rate, and exactly what the replacement should pay.
Frequently asked questions
What is Replace-By-Fee?
Replace-By-Fee is a way to replace an unconfirmed Bitcoin transaction with a new version that spends the same inputs but pays a higher fee. Nodes accept the better paying version and discard the original. It is the cheapest way for a sender to speed up a transaction that was priced too low.
Do I need to have enabled RBF when I sent the transaction?
No, not any more. Bitcoin Core 28 made full RBF the default and Core 29 removed the option to disable it, so every unconfirmed transaction on the network is replaceable regardless of what it signalled. Guides that tell you to look for an RBF flag before bumping are describing rules that no longer apply.
How much does bumping a Bitcoin transaction fee cost?
The difference between the new total fee and the fee already paid, plus a small increment nodes require to accept a replacement. For a typical 250 vB payment going from 0.2 to 1.5 sat/vB that is about 325 satoshis, well under a dollar at current prices.
Can I cancel a Bitcoin transaction with RBF?
Effectively yes, while it is unconfirmed. Broadcast a replacement that spends the same inputs but sends the coins to an address you control, paying a higher fee. The replacement supersedes the original. This is not reliable cancellation though, because a miner could include the original at any moment before your replacement propagates.
Can the receiver of a payment use RBF?
No. Replacing a transaction requires signing a new one with the same inputs, and only the owner of those inputs can do that. If you received a slow payment, use Child Pays For Parent instead by spending the incoming output at a high fee.
Why was my replacement transaction rejected?
Usually because it did not pay enough more than the original. Nodes require a genuine fee increase covering both the higher rate and the bandwidth cost of relaying the replacement. Since Bitcoin Core 31 a replacement can also be rejected if it would break the 64 transaction cluster limit.