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. Our lesson Transaction Fees and Bitcoin’s Security Budget explains how that bidding works.

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 fee estimates on the explorer’s front page. mempool.space labels them Low, Medium and High Priority; High Priority is its estimate for the next block.

If your transaction is paying 2 sat/vB and the next-block band is 80 sat/vB, as in the fee spikes of 2023 and 2024, every transaction bidding more than you goes first, and each block takes only about 1 million vB of them. During a long spike that can mean days, and nodes may even drop a transaction that pays this little (see the edge cases below). That is your signal to act. Fees are far lower as of November 2026: the next block usually needs about 1–2 sat/vB.

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.

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	Sparrow and Electrum won’t replace it (silent payments transactions made in Sparrow are the exception); 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 recipient to CPFP	Nothing for you to bump.

In Sparrow and Electrum, 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. Since Bitcoin Core 28.0 (October 2024), nodes accept a replacement by default even when the original didn’t signal, but Sparrow and Electrum, as they ship, only offer a replacement for transactions that did. The exception is a silent payments transaction made in Sparrow: Sparrow sends it without the signal on purpose and still offers Increase Fee (RBF) for it. Most modern wallets — Sparrow, Electrum, BlueWallet, Bitcoin Core — signal RBF by default now. Older wallets and some exchanges still send non-RBF transactions, which is exactly when you fall back to CPFP. Before you do, check whether your wallet offers Increase Fee anyway.

Your explorer tells you which it is: mempool.space shows a green “RBF” badge on the transaction page when the signal is present, and a red, crossed-out one when it isn’t.

Method 1: Replace-by-Fee (RBF)

RBF broadcasts a new version of the same payment with a higher fee, spending the same inputs. Nodes and miners keep the higher-fee version and drop the original. The recipient normally still receives the same amount to the same address, and your change output shrinks to pay the higher fee. If there is too little change, the wallet may add another of your coins as an input, which links that coin to this payment.

In Sparrow Wallet

1. Open the Transactions tab and select the unconfirmed transaction.
2. If RBF is available, you will see an “Increase Fee (RBF)” option: right-click the transaction, or use the fee-bump icon on its row.
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, or adding another of your coins if there is too little change. Review the inputs, the amount, and 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. Check Method: Preserve payment keeps what the recipient gets, while Decrease payment takes the extra fee out of it (Electrum picks Decrease payment by default if you sent with Max). Then 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.

Before you sign any fee bump in Electrum, compare the whole destination address and the amount with the payment you meant to make, on your hardware wallet’s screen if you have one. Electrum 4.8.3 (October 2026) fixed a flaw that let a malicious server show a fake “stuck” payment to a look-alike address, so that bumping its fee paid the attacker (our advisory). Use 4.8.3 or later; Electrum says users who connect only to servers they trust, such as their own, were not affected.

The BIP-125 rules that bite you

RBF has hard relay rules. BIP-125 first wrote them down, and Bitcoin Core has changed them since. As of Bitcoin Core 32.1, your replacement is rejected by nodes unless:

• It pays a higher absolute fee than everything it replaces (not just a higher rate): the original plus every unconfirmed transaction that depends on it, such as a CPFP child.
• Above that total, it pays enough extra to cover its own bandwidth (its size in vB) at the incremental relay fee: 0.1 sat/vB on Bitcoin Core 29.1 (September 2025) and later, 1 sat/vB on older versions.
• It leaves the mempool better for miners. Since Bitcoin Core 31.0 (April 2026), nodes check that the swap raises what the coming blocks would pay; for a transaction with no unconfirmed parents or children, that check comes down to a higher total fee and a higher fee rate.

In practice: if your original is 200 vB paying 400 sats (2 sat/vB, the same transaction as in the CPFP example below, with no child yet) and the replacement is also 200 vB, nodes on Bitcoin Core 29.1 or later want at least 420 sats, and older nodes at least 600. 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 wasn’t marked RBF, so Sparrow and Electrum won’t replace it (silent payments transactions made in Sparrow aside), 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. In the Transactions tab, right-click the transaction and choose “Increase Effective Fee (CPFP)”. Sparrow opens the Send tab with a child that spends that output.
3. The child sends the coins back 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. Sparrow shows the combined rate next to the fee rate, marked “(CPFP)”. 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. With one unconfirmed parent, that is:

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

If the parent itself spends an output of another unconfirmed transaction that pays less than your target, that one has to be mined first too: add its fee and size to both sums, and do the same further up the chain. Sparrow’s “(CPFP)” rate and Electrum’s “Total feerate” count only the parent you are spending, so check that the parent’s own inputs are confirmed before you trust them.

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: the child makes up the parent’s lowball, as a replacement would, and pays for its own space on top. 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, in Sparrow and Electrum (except Sparrow’s silent payments transactions)	No
Cost	Cheaper (one tx)	More expensive (two txs, child overpays)
Changes txid	Yes (recipient sees new txid)	No (parent unchanged)
Privacy	Reuses inputs (may add one if change is short)	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 inside your own infrastructure, and your fee bump or rebroadcast goes out through your own node rather than a third party’s server. It still has to reach other nodes, so peers can tie it to your IP unless all of your node’s connections go through Tor.

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,” but it is not cancelled: your coins have not moved, and the signed transaction can still confirm if a node or miner kept it. A rebroadcast (your wallet can do this) resends it at the same fee, so nodes only take it back once their mempool minimum falls below its fee rate. To pay more now, replace it with a higher-fee version that spends the same coins (RBF, or coin control to pick them). Never resend the payment from different coins: if both confirm, you pay twice.
• 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. Only the exchange can replace its own withdrawal, and many send them in large batches. You can still CPFP the coins you received, but your child then pays for the whole batch, so check the parent’s size first: for a big batch, waiting or asking the exchange to bump it is usually cheaper. Our lesson Your First Withdrawal: From an Exchange to Your Own Wallet works through an example.

The one-line summary

If you sent it and it signaled RBF, or it’s a silent payments transaction made in Sparrow, 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 you never look up your txid on someone else’s explorer. Then watch it confirm.