RBF vs CPFP: How to Speed Up a Stuck Bitcoin Transaction

When a Bitcoin transaction is stuck because the fee was too low, you have two ways to speed it up: Replace-by-Fee (RBF) and Child-Pays-for-Parent (CPFP). They solve the same problem from opposite ends. The simple rule: use RBF when yousent the transaction, and CPFP when you're receivingit. Here's how each works and when to reach for which.

Replace-by-Fee (RBF): bump your own transaction

RBF lets you replace a stuck, unconfirmed transaction with a new version of the same transaction that pays a higher fee. The replacement out-bids the original and jumps back up the queue; miners confirm the new one and the old one is discarded.

When you can use it

• →You sent the transaction — RBF only works on transactions you created.
• →It was flagged as RBF-enabled when you broadcast it. Many wallets enable this by default; some let you toggle it per send.
• →It's still unconfirmed. Once it confirms, there's nothing to replace.

How to do it

In a supporting wallet, open the pending transaction and look for “Bump fee,” “Increase fee,” or “Speed up.”The wallet rebuilds the transaction with a higher rate and rebroadcasts it. The extra fee comes out of your change output, so there's nothing new to deposit. Check a live trackerfirst so you bump to a rate that's actually competitive right now.

Child-Pays-for-Parent (CPFP): pull a transaction through

CPFP is for when you can't edit the stuck transaction — most often because someone sentBitcoin to you and it's stuck. You create a new transaction (the “child”) that spends the unconfirmed incoming output, and you attach a high fee to it. Because a miner can only collect the child's juicy fee by also confirming its unconfirmed parent, they pull both into a block together.

When you can use it

• →You're receiving a stuck transaction (you can't RBF someone else's send).
• →RBF wasn't enabled on a transaction you sent, but you control one of its outputs.
• →Your wallet supports it — CPFP is more advanced and not in every wallet.

The catch

The child's fee has to be high enough to cover bothtransactions' share of block space, so CPFP can get expensive — the worked example below shows exactly how much. It's a rescue tool, not a routine one.

Worked example: what each fix actually costs

Fees are paid per virtual byte, so the size of each transaction sets the bill. A typical single-input, two-output SegWit spend is around 140 vB. (If sat/vB is unfamiliar, start with how Bitcoin fees are calculated.) Every number below is illustrative; check a live tracker for real rates.

The RBF case

Say you sent a 140 vB transaction at 2 sat/vB — a 280-sat fee — and it turns out next-block confirmation is going for 20 sat/vB. Your bump rebuilds the same 140 vB transaction at 20 sat/vB: 2,800 sats. Only the version that confirms pays its fee, so the mistake costs about 2,520 sats more than pricing it right the first time. Annoying, but cheap.

The CPFP case

Now suppose the stuck transaction is an incoming200 vB payment that paid 2 sat/vB (400 sats), and confirmation still requires 20 sat/vB. Miners judge parent and child together as a package, so the pair must average 20 sat/vB across their combined 340 vB — 6,800 sats total. The parent contributed 400, leaving your 140 vB child to cover 6,400 sats: roughly 46 sat/vB on the child alone, more than double the going rate. That is the structural reason CPFP costs more than RBF — you're buying block space for two transactions with one fee.

RBF vs CPFP at a glance

• →Who controls it: RBF — the sender. CPFP — usually the receiver (or anyone who controls an output).
• →What it does: RBF replaces the transaction. CPFP adds a second transaction that drags the first along.
• →Requirement: RBF needs the original to be RBF-enabled. CPFP needs a spendable unconfirmed output.
• →Cost: RBF is usually cheaper and cleaner. CPFP pays for two transactions' worth of space.
• →Best for: RBF — “I sent it and it's stuck.” CPFP — “I'm waiting on a stuck incoming payment.”

Mistakes that keep transactions stuck

• →Bumping in timid increments. Going from 2 to 4 to 6 sat/vB while blocks are clearing at 20 just re-parks you at the back of the queue each time. Look at where the mempool is actually clearing and make one decisive bump to a confirming rate.
• →Forgetting that RBF changes the txid. A replacement is a new transaction with a new ID. If a merchant or exchange is watching the original txid, their tracking link goes dead even though the payment arrives — tell them you bumped.
• →Spending unconfirmed change from the stuck transaction.The new send inherits the parent's problem and can't confirm until it does. Unless you priced the child high on purpose (which is just CPFP), you now have two stuck transactions.
• →Paying an “accelerator” you don't need.Legitimate out-of-band accelerators exist, but they usually cost far more than a plain RBF bump. The free “rebroadcast” sites do essentially nothing. Exhaust RBF and CPFP first.
• →Rescuing a payment smaller than the rescue.If the stuck incoming amount is tiny, a CPFP child's fee can eat most of it. Run the math from the worked example above before spending more on the rescue than the payment is worth.

Edge cases worth knowing

The transaction didn't signal RBF

Signaling used to be a hard requirement. These days much of the network relays replacements whether or not the original opted in (“full RBF”), so a bump often works anyway. Wallet support is inconsistent, though — treat it as a bonus, not a plan. If your wallet refuses, CPFP on your own change output is the reliable fallback.

You can cancel, not just accelerate

An RBF replacement doesn't have to pay the same recipient. Replace the stuck send with a transaction that pays everything back to your own address and you've effectively cancelled it. One warning: until the replacement confirms, either version can still win, so never treat a cancel as final until it has a confirmation.

When neither tool applies

If an exchange sent you a withdrawal, you didn't create the transaction, so you can't RBF it — but it pays an output to you, so CPFP from your wallet still works. The genuinely stuck case is a payment you sent from a custodial service to a third party: only the service can fix that one. Long chains of unconfirmed transactions can also hit node relay limits that block further children — one more reason to wait for a confirmation before stacking new spends on top.

Better than fixing: avoid it

• →Check the live rate before sending — see what a good fee is right now.
• →Leave RBF enabled so you always have the easy fix available.
• →Send during quiet windows — see the cheapest time to send.

The bottom line

RBF and CPFP are the two safe ways to rescue an underpaid Bitcoin transaction. Bump your own send with RBF; pull a stuck incoming payment through with CPFP. Both keep your coins fully under your control — and most of the time, checking the live fee before you send means you'll never need either one.

Send at the right rate the first time with the SatSaver tracker. Mempool data from mempool.space.