How to Unstick a Bitcoin Transaction: RBF and CPFP Fee-Bumping Walkthrough

Your transaction has been “pending” for six hours. The recipient is asking where their sats are. You broadcast it during a fee spike, lowballed the fee rate, and now it is sitting in the mempool while higher-paying transactions confirm ahead of it. This is not a lost transaction, and you do not need to wait passively. You can bump the fee yourself.

There are exactly two mechanisms for this, both built into Bitcoin: Replace-by-Fee (RBF) and Child-Pays-for-Parent (CPFP). Which one you use depends on whether you sent the transaction or received it, and on a single flag that was set when the transaction was first signed. This walkthrough covers both, using Sparrow and Electrum connected to your own node, with the exact decision logic and the trade-offs nobody mentions until you hit them.

First: confirm the transaction is actually stuck

A transaction is “stuck” when its fee rate (measured in satoshis per virtual byte, sat/vB) is below what the network is currently demanding to confirm in the next few blocks. It is not stuck because of a bug. It is stuck because you underbid.

Pull up your transaction ID (txid) on a mempool explorer. mempool.space is the standard; if you run your own node, point it at your own mempool.space instance so you are not leaking your txid to a third party. Look for two things:

• The transaction’s fee rate, shown in sat/vB.
• The current mempool fee bands — the “next block,” “3 blocks,” and “6 blocks” fee estimates shown on the explorer’s front page.

If your transaction is paying 4 sat/vB and the next-block band is 80 sat/vB, you are roughly 20 blocks deep in the backlog at best, and during a sustained spike you may never confirm before the next mempool purge. That is your signal to act.

Do not assume a transaction is stuck after ten minutes. Block times vary; a 30-minute gap between blocks is normal variance. Wait for confirmation only if your fee rate is comfortably inside the next-block band.

The decision: RBF or CPFP?

Use this table. It resolves 95% of cases.

Situation	Method	Why
You sent it AND it was marked RBF	RBF	Cleanest, cheapest. Replace the tx with a higher-fee version.
You sent it but it was NOT marked RBF	CPFP	You can’t replace it; spend its change output with a high-fee child.
You are receiving it (no control over the sender)	CPFP	Spend the incoming output yourself with a high-fee child.
It has no spendable output you control	Wait, or ask the sender to RBF	Nothing for you to bump.

The pivot is whether the transaction signaled RBF. This was decided when it was signed. Under BIP-125, a transaction signals replaceability by setting at least one input’s nSequence value below 0xfffffffe. Most modern wallets — Sparrow, Electrum, BlueWallet, Bitcoin Core — enable RBF by default now. Older wallets and some exchanges still send non-RBF transactions, which is exactly when you fall back to CPFP.

Your explorer tells you which it is: mempool.space shows an “RBF” badge on the transaction page when the signal is present.

Method 1: Replace-by-Fee (RBF)

RBF rebroadcasts the same transaction with a higher fee, using the same inputs. Miners prefer the higher-fee version and drop the original. The recipient still receives the same amount to the same address — only the fee changes (and possibly your change output shrinks to pay for it).

In Sparrow Wallet

1. Open the Transactions tab and select the unconfirmed transaction.
2. If RBF is available, you will see an “Increase Fee” option (right-click the transaction or use the transaction detail pane).
3. Sparrow shows the current fee and a new fee-rate slider. Set the new rate at or above the current next-block estimate — Sparrow pulls live estimates if connected to your node or a server. During a spike, overshoot slightly; matching the band exactly risks falling behind if fees keep climbing.
4. Sparrow constructs the replacement, deducting the extra fee from your change output. Review the new fee in sat/vB and total sats.
5. Sign (with your hardware wallet — Coldcard, BitBox02, Foundation Passport, Jade, Trezor, Keystone — or hot key) and broadcast.

The replacement appears with the same destination but a new txid. The old one disappears from the mempool within seconds.

In Electrum

1. Right-click the unconfirmed transaction in the History tab.
2. Select “Increase fee.”
3. Choose a new fee rate. Electrum offers a target (in blocks) or a manual sat/vB value. Manual is better when you want precise control during a spike.
4. Confirm, sign, broadcast.

The BIP-125 rules that bite you

RBF has hard relay rules. Your replacement is rejected by nodes unless:

• It pays a higher absolute fee than the original (not just a higher rate).
• It pays enough extra to cover its own bandwidth at the minimum relay fee (typically 1 sat/vB on top).
• It does not add new unconfirmed inputs that conflict with mempool policy.

In practice: if your original paid 1,000 sats total, a replacement paying 1,050 sats may be rejected if the size grew. Bump generously. A replacement that targets the next-block band almost always clears these thresholds with room to spare.

Method 2: Child-Pays-for-Parent (CPFP)

CPFP is for when you cannot replace the transaction — either it was non-RBF, or you are the receiver and have no signing authority over it. The trick: miners evaluate transactions by package fee rate, not individual fee rate. If you create a new transaction (the “child”) that spends an output of the stuck transaction (the “parent”) and attach a very high fee, a miner who wants the child’s fat fee must also include the parent. They confirm together.

You need a spendable output from the stuck transaction. That means either the change output (if you sent it) or the received output (if it was sent to you). If you sent a non-RBF payment to someone else and kept no change, you have nothing to spend, and only the recipient can CPFP it.

In Sparrow

1. Select the unconfirmed transaction. Find the output that pays an address you control (your change, or the received amount).
2. Right-click that UTXO in the UTXOs tab and choose to spend it, or use the explicit “Create CPFP” action where available.
3. Send the child transaction to one of your own addresses (a self-spend). The destination amount barely matters; the fee is the point.
4. Set the child’s fee rate high enough that the combined package averages above the next-block band. This is the math people skip — see below.
5. Sign and broadcast.

In Electrum

1. Right-click the unconfirmed incoming/change output transaction.
2. Select “Child pays for parent.”
3. Electrum calculates the required child fee to lift the package to your chosen target rate. Accept or adjust.
4. Sign, broadcast.

Electrum doing the package math for you is the single best reason to reach for it in a CPFP emergency.

The CPFP math you must get right

The miner cares about the combined fee rate:

package_rate = (parent_fee + child_fee) / (parent_vsize + child_vsize)

Say the parent is 200 vB paying 2 sat/vB (400 sats) and you want the package to hit 80 sat/vB. A typical child is ~150 vB. Solve:

80 = (400 + child_fee) / (200 + 150)
80 × 350 = 400 + child_fee
28,000 - 400 = child_fee
child_fee = 27,600 sats  →  ~184 sat/vB on the child

The child has to pay an eye-watering rate to drag the cheap parent up to target. This is the core trade-off: CPFP is more expensive than RBF because you are paying for two transactions’ weight, and the child overpays to compensate for the parent’s lowball. Where you have RBF available, use RBF.

RBF vs CPFP: the honest comparison

	RBF	CPFP
Who can use it	Sender only	Sender or receiver
Requires RBF flag	Yes	No
Cost	Cheaper (one tx)	More expensive (two txs, child overpays)
Changes txid	Yes (recipient sees new txid)	No (parent unchanged)
Privacy	Reuses inputs	Adds a new linked tx
Best for	Your own stuck payment	Stuck incoming funds, or non-RBF you sent

Doing this on your own node

Both methods work over any wallet, but doing them against your own full node matters here for two reasons. First, fee estimation: your node’s mempool is the ground truth for what is actually competing for block space right now, and Sparrow or Electrum querying your own Bitcoin Core gives you honest, unleaked estimates. Second, privacy: looking up your stuck txid on a public explorer ties your IP to that transaction. Running mempool.space or Bitcoin Core’s RPC locally (Umbrel, Start9, RaspiBlitz, MyNode all bundle this) keeps the lookup and the rebroadcast inside your own infrastructure.

In Sparrow, set the server to your own bitcoind or Electrum server. In Electrum, point it at your own ElectrumX/Electrs instance. Fee bumping then uses your node’s real-time view instead of a third party’s.

Edge cases worth knowing

• The mempool purges your tx. If a transaction’s fee rate is below the dynamic mempool minimum during extreme congestion, nodes evict it entirely. It will look “dropped.” It is not spent — your coins are safe. Simply rebroadcast (your wallet can do this) at a sane fee rate, or wait for fees to fall and rebroadcast then.
• Whole-package eviction. A very-low-fee parent can drag a CPFP child out of the mempool too. Bump the package high enough to stay above the eviction floor.
• Recipient already saw it. RBF changes the txid. If a merchant is watching the original txid, warn them before you replace it, or they may flag the payment as disappeared.
• Exchange withdrawals. Many exchanges send non-RBF and keep the change, so you cannot bump their withdrawal at all. You wait. This is a reason to prefer wallets and services that signal RBF.

The one-line summary

If you sent it and it signaled RBF, bump it with RBF in Sparrow or Electrum — cheapest fix. If you cannot replace it (non-RBF, or you are receiving), spend its output with a high-fee CPFP child and make sure the combined package rate clears the next-block band. Do both against your own node so your fee estimates are honest and your txid stays private. Then watch it confirm.