Replace-By-Fee: Unsticking a Slow Transaction

Replace-by-fee lets a sender swap a stuck, unconfirmed Bitcoin transaction for a version that pays a higher fee. Since Bitcoin Core 28.0 (2 October 2024), nodes accept such replacements by default whether or not the original signalled, so a receiver should treat every unconfirmed payment as a promise until it confirms.

Category: Mining and the Network · Published 2026-10-28

Editorial review complete · technical review pending · sources under review

What does this mean?Editorial review covers clarity and neutrality. Technical, security, and source reviews indicate whether an article's material claims were checked against relevant authoritative material. A source link being available does not by itself mean every claim has been verified. A reviewed status means the article's material claims were examined; it does not mean the article is exhaustive or that future protocol, market, or software changes cannot make it outdated.

Why transactions get stuck in the first place

Every Bitcoin transaction you send first lands in the mempool, short for "memory pool": the waiting room of unconfirmed transactions that each node keeps in memory. It stays there until a miner picks it up and packs it into a block, which takes about ten minutes on average for a transaction paying a sufficient fee.6

Miners can only fit so many transactions into each block, so they tend to choose the ones offering the most fee for the space they take up, measured in satoshis per virtual byte.5 Think of it as a crowded venue: the fee is your tip to the usher, and the best tippers get seated first.

When the network is busy and you attached a fee that was too low, your transaction can sit unconfirmed for hours or even days: perfectly valid, but stuck near the back of the line. By default, Bitcoin Core caps its mempool at 300 MB of memory and forgets any transaction that has waited two weeks, although the wallet that sent it may broadcast it again.8

What Replace-By-Fee actually does

Replace-By-Fee (RBF) is the standard way to move a stuck transaction forward. Instead of waiting, your wallet builds a new version of the same transaction that spends the same coins but attaches a higher fee, then broadcasts it to the network. Nodes accept the replacement only if it pays at least as much in total as the transaction it replaces, plus a little extra to cover relaying it.2

Because both versions spend the same inputs, only one of them can ever confirm. Nodes that accept the replacement drop the original from their mempools, so miners see the better-paying version and the original quietly falls away. You have effectively re-tipped the usher without leaving the queue.

The rules on which transactions may be replaced have changed over time. BIP 125, assigned in December 2015, made replacement opt-in: a transaction signals that it may be replaced by setting a field called nSequence below a set value on at least one input.1 Bitcoin Core followed that opt-in rule for years. Since version 28.0, released on 2 October 2024, its nodes accept replacements of unconfirmed transactions by default whether or not they signalled, and the current policy no longer requires the signal at all.23 Wallets have moved more slowly: Bitcoin Core's own wallet could only bump a transaction that signalled until version 30.0, released in October 2025.4

How to bump a fee in your wallet

In practice you rarely touch any of this by hand. Wallets that support RBF show a button labelled something like Bump Fee, Boost, or Speed Up next to a pending transaction. Tap it, confirm the new higher fee, and the wallet does the rest.

A few things worth knowing:

  • The extra fee is real money. It usually comes out of your change, the leftover coins returning to you, so a bump means you keep a little less.
  • You can bump more than once if the network stays busy, as long as each new version pays more than the one before.2
  • If your wallet cannot bump the transaction, Child-Pays-For-Parent (CPFP) can sometimes rescue it: whoever controls one of its unconfirmed outputs, often the receiver, spends those coins in a new, high-fee transaction, giving miners a reason to confirm both at once.5

Bumping pending is not reversing confirmed

This is the part that trips people up, so let's be precise. Bumping the fee on a pending transaction is not the same as reversing a confirmed one.

An unconfirmed transaction is a proposal. Nothing has been settled, and anyone watching the network should assume it might still change, which is exactly what RBF does. Nobody who was paying attention has lost money they actually held, because the payment was never settled.

A confirmed transaction is a different animal. Once it is in a block, undoing it would mean building a competing chain without it, a "reorg", and out-working the rest of the network until that chain is longer. The newest block is occasionally replaced by accident, which is why one confirmation is not quite final, but an attacker's chance of catching up falls exponentially with every block added on top.67 RBF touches only the unconfirmed layer; it can never claw back a settled payment.

Zero-conf: what receivers should know

Accepting a payment the instant you see it, before any block confirms it, is called zero-confirmation, or "zero-conf." It feels instant and convenient, but it rests on trust, because an unconfirmed transaction can still be replaced or dropped.6

If you receive bitcoin, keep a few habits:

  • Treat a zero-conf payment as a promise, not a settled fact. BIP 125 told receivers to be wary of transactions that signal replacement; now that Bitcoin Core accepts replacements of any unconfirmed transaction by default, that caution applies to all of them.12
  • Wait for at least one confirmation before handing over anything irreversible. For high-value payments, the Bitcoin developer guide suggests waiting for at least six.6
  • Remember that a sender can replace an unconfirmed transaction with one that pays you less, or nothing, before it confirms.

Confirmations are what turn a promise into a payment.

Honest limits and caveats

RBF is a useful tool, not a magic undo. A few honest limits to keep in mind:

  • It only works while the transaction is unconfirmed. The moment a block includes it, RBF is off the table for good.
  • It cannot lower your total cost. Every bump adds fee; it never refunds it.2
  • A bump is not a guaranteed cancel button. Some wallets let you redirect an unconfirmed transaction back to yourself, but if the original is mined first, you are too late.
  • If your wallet offers no bump option, it may not support fee-bumping, or it may only bump transactions that signalled when they were sent. CPFP or simple patience may be your only routes.

Used calmly, fee-bumping is just the network working as designed: a way to say "actually, I'll tip a bit more" while your transaction is still waiting.

FAQ

Does Replace-By-Fee cost extra?

Yes. The whole point is to attach a higher fee, and the replacement must pay at least as much as the original plus a little more for its own relay. That extra comes out of your own funds, usually your change output, so you end up keeping slightly less than before.

Can I use RBF to cancel a payment I already sent?

Sometimes, but only while it is still unconfirmed. Some wallets let you replace a pending transaction with one that sends the coins back to yourself. There is no guarantee it will work, and once the original transaction confirms in a block, it is final and cannot be canceled.

Is Replace-By-Fee a form of double-spending or cheating?

Only in the narrow sense that two versions spend the same coins and just one of them can confirm, which is exactly why a receiver should wait for a confirmation. It is not cheating the network: nodes follow published replacement rules, and RBF cannot touch a payment once it is in a block. Reversing a confirmed payment would mean out-mining the rest of the network, which gets exponentially harder with every block added on top.

My wallet has no bump fee button. What now?

Your wallet may not support fee-bumping, or may only bump transactions that signalled replaceability when sent. If you control one of the transaction's outputs, such as the payment you received, Child-Pays-For-Parent may speed it up. Otherwise, wait: busy periods pass. Bitcoin Core nodes forget an unconfirmed transaction after two weeks by default, but the sending wallet may broadcast it again, so check a block explorer rather than assuming it is gone.

How many confirmations should a receiver wait for?

It depends on the value at stake. Zero confirmations is risky and best avoided for anything you cannot reverse. One confirmation cuts the risk sharply, though the newest block is occasionally replaced by accident. For high-value payments, the Bitcoin developer guide suggests waiting for at least six confirmations, about an hour, before treating a payment as settled.

Key takeaways

  • Replace-by-fee swaps an unconfirmed transaction for a version that spends the same coins with a higher fee.
  • A replacement must pay more in total than the original, so a bump always costs extra and only one version can confirm.
  • Since Bitcoin Core 28.0 (2 October 2024), nodes accept replacements by default whether or not the original signalled under BIP 125.
  • Child-pays-for-parent is the fallback when a wallet cannot bump: a high-fee child pulls its parent into a block.
  • RBF cannot touch a confirmed payment, but receivers should wait for at least one confirmation, and at least six for high-value payments.

Sources

  1. BIP 125, Opt-in Full Replace-by-Fee Signaling (assigned December 2015): a transaction signals it may be replaced when an input's nSequence is below 0xfffffffe; the original replacement rules; advice that receivers treat signalled transactions with suspicion until confirmed — Bitcoin Improvement Proposals (GitHub)
  2. Bitcoin Core mempool replacement policy: a replacement must pay at least the fees of the transactions it replaces plus its own relay cost; full replace-by-fee is the default as of v28.0; signalling is no longer required — Bitcoin Core project (GitHub)
  3. Bitcoin Core 28.0 release notes (2 October 2024): the default of -mempoolfullrbf changed from 0 to 1 — Bitcoin Core
  4. Bitcoin Core 30.0 release notes (10 October 2025): the wallet's bumpfee and psbtbumpfee allow a replacement under full RBF and no longer require BIP 125 signalling — Bitcoin Core
  5. Child pays for parent (CPFP): spending an output of a low-fee unconfirmed transaction in a high-fee child so miners include both; Bitcoin Core selects transactions for its block templates by ancestor fee rate — Bitcoin Optech
  6. Bitcoin Developer Guide, Payment Processing (Verifying Payment): about ten minutes on average to a first confirmation; what 0, 1, 2 and 6 confirmations mean; unconfirmed payments should not be trusted without risk analysis; at least six confirmations for high-value payments — Bitcoin Project (developer.bitcoin.org)
  7. Bitcoin: A Peer-to-Peer Electronic Cash System (the whitepaper), section 11: an attacker's chance of catching up with the honest chain drops exponentially with each block added — bitcoin.org
  8. Bitcoin Core source, mempool_options.h: default maximum mempool size of 300 MB and default expiry of unconfirmed transactions after 336 hours (two weeks) — Bitcoin Core project (GitHub)

Related educational reading