RBF Fee Bumper — Unstick a Bitcoin Transaction

What is a stuck Bitcoin transaction?

Every unconfirmed Bitcoin transaction competes for a limited amount of block space. Each block can hold roughly 1–4 MB of transaction data (depending on transaction types), and miners select transactions to include based on the fee rate — sats per virtual byte (sat/vB) — each one offers. When you broadcast a transaction with a fee rate that turns out to be too low, it sits in the mempool waiting for a miner to pick it up.

This happens most often during fee spikes. You sent a transaction at 5 sat/vB on a quiet afternoon, and by the time a miner looks at the mempool, the minimum to get in the next block is 25 sat/vB. Your transaction is now near the bottom of the queue, and it may stay there for hours, days, or until the congestion clears.

The funds are not lost. They are frozen in limbo: the sender cannot spend those inputs (they are “locked” by the unconfirmed transaction), and the recipient sees a perpetually unconfirmed incoming payment. For time-sensitive payments — paying a lightning service provider, closing an escrow, meeting a deadline — this is a real problem.

There are two primary solutions: Replace-by-Fee (RBF) and Child-Pays-for-Parent (CPFP).

RBF: Replace-by-Fee

RBF is specified in BIP 125. It allows the sender of a transaction to broadcast a new version of the same transaction — spending the same inputs, paying the same outputs — but with a higher fee. Miners will prefer the higher-fee replacement, and once it confirms, the original transaction is gone.

For RBF to work, the original transaction must have signaled RBF by setting at least one input’s sequence number to a value below 0xFFFFFFFE. Most modern wallets do this automatically:

• Sparrow Wallet — signals RBF on all transactions by default; has an explicit “Increase Fee” button
• Bitcoin Core — RBF is the default; use bumpfee in the console or the GUI option
• Electrum — supports RBF; right-click a pending transaction to bump
• mempool.space Accelerator — for transactions that cannot be RBF’d, mempool.space offers a CPFP-based acceleration service

If your original transaction did not signal RBF, you cannot use this method. Your options then are CPFP (if you are the recipient) or waiting.

BIP 125 replacement rules in detail

BIP 125 defines five conditions the replacement transaction must satisfy. The two most relevant for fee bumping are:

Higher absolute fee: The replacement must pay a strictly higher total fee in satoshis than the original. It is not enough to simply pay a higher fee rate — if the replacement transaction is smaller (fewer bytes), the total fee could be lower even at a higher rate. This rarely matters in practice because fee bumps usually keep the same transaction shape.

Relay fee increment floor: The replacement fee must be at least the original fee plus 1 sat/vB × vbytes_of_replacement. This prevents an attacker from spamming replacements with negligibly higher fees. The BIP 125 floor is what this calculator computes and enforces — if your chosen new rate falls below it, the replacement will be rejected by relay nodes.

BIP 125 also requires that the replacement does not add new unconfirmed inputs, and that the number of conflicted transactions it evicts does not exceed 100.

CPFP: Child-Pays-for-Parent

Child-Pays-for-Parent (CPFP) is the complementary mechanism. It works when:

• You are the recipient of the stuck transaction (not the sender, so you don’t have the sender’s keys)
• The sender’s wallet did not signal RBF
• You want to accelerate without invalidating or changing the original transaction

In CPFP, you create a child transaction that spends one of the unconfirmed outputs (the money you received). You set the child’s fee high enough that the combined fee rate of the parent + child package exceeds the current mempool minimum. Miners evaluate the package as a unit, so a sufficiently generous child can pull the stuck parent into the next block.

CPFP has a drawback: you are paying fees on two transactions (the parent you didn’t send and the child you’re creating). For small amounts, this can be economically irrational — you’d spend more on acceleration fees than the transaction is worth. RBF is generally cheaper when available because the sender is only paying one fee, not two.

When to use RBF vs CPFP

How to bump via popular wallets

Sparrow Wallet: Open the transaction in the Transactions tab. If it is unconfirmed and RBF-enabled, you’ll see an “Increase Fee” button. Click it, set your target fee rate, and Sparrow builds and broadcasts the replacement automatically.

Electrum: In the History tab, right-click the pending transaction and choose “Increase fee.” Electrum shows you the current fee and lets you set a new fee rate. Sign and broadcast.

Bitcoin Core (GUI): Right-click the pending transaction in the Transactions tab and select “Bump fee.” The GUI prompts for a new fee rate and handles the rest.

Bitcoin Core (console): bumpfee <txid> — optionally pass {"fee_rate": N} as a second argument.

mempool.space: If your transaction doesn’t qualify for RBF, mempool.space provides a CPFP-based acceleration service. Paste your txid and pay a fee to have them package-mine it.

Warnings and caveats

RBF signal required: If the original transaction’s sequence numbers do not signal RBF, Bitcoin nodes will not propagate the replacement. Check your wallet’s settings before assuming you can always bump.

Recipients may see the original as unconfirmed payment: Some wallets and merchants show unconfirmed received transactions immediately. A RBF bump technically invalidates the original transaction — the recipient will see it disappear and a new transaction appear with the same amount but different txid. Communicating this to the recipient avoids confusion.

Double-spend risk for recipients: Because RBF allows the sender to broadcast conflicting transactions, a dishonest sender could theoretically use RBF to attempt a double-spend by replacing a transaction to merchant A with a transaction to merchant A with a lower amount — or even to a change address they control. Merchants who accept zero-confirmation Lightning or on-chain payments should be aware of this. For large amounts, waiting for one or more confirmations is always safer.

Not all wallets are equal: Some older wallets or exchange-operated wallets do not signal RBF by default. If you use such a wallet, you may not be able to bump at all without the cooperation of the receiving party.

FAQ

Why does the BIP 125 floor matter?

Without the relay floor, an attacker could spam the mempool with endless 1-sat incremental replacements, forcing nodes to validate and propagate an unlimited number of transactions. The 1 sat/vB increment requirement means each replacement must pay the relaying node economically, making fee-spam attacks expensive enough to be impractical.

What happens to my original transaction after a successful RBF?

It disappears. Once the replacement confirms, the original transaction is invalid — it spent the same inputs that are now consumed by the confirmed replacement. Any recipient who saw the original unconfirmed will see it vanish from their wallet and the replacement (with possibly a different txid) will confirm instead.

Can I RBF a transaction I received?

No. RBF requires spending the same inputs as the original transaction, which means you need the private keys that signed the original inputs. As a recipient, you can only use CPFP.

How do I know if my wallet signals RBF?

Check Settings or Preferences in your wallet. Sparrow, Bitcoin Core, and Electrum all have RBF settings. If you’re unsure, look up the original transaction on a block explorer: a transaction signals RBF if any input has a sequence number less than 0xFFFFFFFE (4294967294). mempool.space displays this explicitly.

Sources:

• BIP 125 (Replace-by-Fee signaling): github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
• mempool.space live fee rates: mempool.space
• Sparrow Wallet RBF: sparrowwallet.com