Child Pays for Parent (CPFP): The Other Way to Unstick a Bitcoin Transaction

Most Bitcoin beginners learn the term RBF (Replace-by-Fee) the first time one of their transactions gets stuck in the mempool. They open a guide, replace the transaction with a higher-fee version, and the problem disappears. Great. But what happens when the wallet did not flag the original transaction as RBF-enabled, or you are the receiver staring at a pending payment that the sender refuses to fix? RBF is not an option in either case. That is where Child Pays for Parent — CPFP — comes in.

CPFP is the other half of the “how to unstick a Bitcoin transaction” toolkit. It is not nearly as well-known as RBF, mostly because for years it required a hardware wallet, a desktop client, and the willingness to type the phrase coin control into a search bar. In 2026, mainstream wallets like Sparrow, BlueWallet, Electrum, and even a few mobile wallets have made it click-three-times simple. This article is the plain-English explanation.

The 60-second version

When a Bitcoin transaction sits unconfirmed in the mempool because the fee is too low, miners simply will not include it in a block. There are two ways to bribe them into doing so:

1. RBF (Replace-by-Fee): you, the sender, rebroadcast the same transaction with a higher fee. Miners see both versions and confirm the richer one. The original is dropped. RBF only works if the original transaction was marked as replaceable when it was sent.
2. CPFP (Child Pays for Parent): the receiver (or anyone holding one of the outputs) spends the unconfirmed coins in a new transaction, attaching a fat fee. Bitcoin’s mempool logic says “to confirm the child, I have to confirm the parent first.” The miner does the math on the combined fee rate, decides it is worth their time, and packages both into the next block.

RBF rewrites history. CPFP appends to it. If you understand that one sentence, you understand 80% of the topic.

Why CPFP exists in the first place

Bitcoin miners are profit-maximizing service providers. Each block has about 1MB of usable space, so when fee rates rise, miners always pick the highest fee-per-byte transactions available. A 1,000-byte transaction paying 10,000 satoshis (10 sat/byte) gets confirmed before a 1,000-byte transaction paying 2,000 satoshis (2 sat/byte). That is the entire ordering rule.

If you accidentally broadcast a 2 sat/byte transaction during a 50 sat/byte fee market, your transaction goes into limbo. The mempool keeps it for up to 14 days (default), then drops it. While it is in limbo, you cannot spend the coins it created — both as the sender (your change output is locked) and as the receiver (the incoming output is unconfirmed).

Before CPFP existed at the protocol level (specifically, before mempool packages and ancestor fee calculations were polished into Bitcoin Core), miners only looked at each transaction’s standalone fee rate. The stuck child of a stuck parent would never get mined no matter how rich the fee. Today, miners use ancestor-aware fee calculation: they look at a transaction’s effective fee rate including all of its unconfirmed parents. That is what makes CPFP work.

When CPFP is the right tool

You reach for CPFP in three common situations:

1. You are the receiver. The sender broadcast a low-fee transaction and won’t fix it.

This is by far the most frequent CPFP use case. An exchange sends a customer their withdrawal at a fee rate that worked yesterday but is now too low. The exchange’s automated systems don’t handle re-broadcasts and customer support is 14 emails deep. You can wait. Or you can spend the still-unconfirmed coins to yourself with a fat fee and pull the parent transaction along.

2. You sent the original transaction without RBF flagged.

Some wallets default to non-replaceable (also called “final”) transactions for security or compatibility reasons. Coinbase used to do this for retail customers. If your wallet doesn’t allow RBF, you cannot replace the transaction. But you can spend the change output (the leftover Bitcoin that came back to you) in a new high-fee transaction to drag the original through.

3. Both the parent and a child are stuck.

If you sent transaction A, then immediately sent transaction B that spent A’s output, and both are now languishing at a low fee, RBF won’t help because it only rewrites one of them. CPFP can lift the entire chain in a single new high-fee transaction. (For experts: this is the “package” case, and modern wallets handle it automatically.)

The exact wallet steps (Sparrow, BlueWallet, Electrum)

Sparrow Wallet (desktop)

Sparrow is the most powerful and most beginner-friendly Bitcoin desktop wallet in 2026. CPFP is built in:

1. Open your wallet. Click Transactions.
2. Find the unconfirmed transaction in the list. It will show a yellow clock icon.
3. Right-click and choose Bump Fee → Child Pays for Parent.
4. Sparrow opens a fee-bump dialog. The target fee rate it suggests is the combined rate needed to land both transactions in the next 1–3 blocks at current market.
5. Confirm. Sparrow builds a new spend-to-yourself transaction using the unconfirmed output, signs it, and broadcasts.

If your unconfirmed output is on a hardware wallet, plug it in to sign. Done.

BlueWallet (mobile)

BlueWallet’s mobile CPFP is straightforward:

1. Tap the wallet, then the unconfirmed transaction.
2. Look for the “...” menu or a button labeled CPFP — Bump Fee (Child Pays for Parent).
3. Choose a new fee rate. BlueWallet will pre-fill a value that should get the parent confirmed within 1–3 blocks.
4. Confirm and broadcast.

BlueWallet’s CPFP only works if you can spend one of the outputs. As the sender, you spend the change output; as the receiver, you spend the incoming output. If the transaction sent all the funds away and you are not the receiver, there is nothing on your side to bump — the only option is to ask the receiver to do CPFP on their end.

Electrum (desktop)

Electrum has had CPFP for years and the UX has stayed stable:

1. Open the History tab.
2. Right-click the unconfirmed transaction.
3. Choose Child pays for parent.
4. Set the new fee rate. Electrum will show you the effective combined rate.
5. Sign and broadcast.

How to pick the right fee rate

The single biggest mistake people make with CPFP is using a fee rate that is too low. Remember: the goal is to make the combined rate (parent + child) attractive to miners. If the parent is 100,000 bytes at 2 sat/byte (so 200,000 sats of fee at a 2 sat/byte effective rate) and you create a 200-byte child paying 50,000 sats, the combined math is:

(200,000 + 50,000) / (100,000 + 200) = 250,000 / 100,200 ≈ 2.49 sat/byte

That barely moves the needle. To pull a 2 sat/byte parent into a 50 sat/byte market, the child has to pay a lot:

• Target combined rate: 50 sat/byte
• Combined size: ~100,200 bytes
• Required combined fee: ~5,010,000 sats
• Existing parent fee: 200,000 sats
• Child has to pay: ~4,810,000 sats on a 200-byte transaction

That is the cost of bailing yourself out at peak fees. The math is brutal but the principle is correct: the child carries the entire deficit.

Practical rule of thumb: check mempool.space for the current “next block” fee rate, then pick a child fee that brings the combined rate to that target. Every modern wallet does this math for you when you open the CPFP dialog — the number it suggests is usually close to optimal.

CPFP vs RBF: which one should you use?

If both options are available, RBF wins on cost. RBF only requires you to pay the difference between the old fee and the new fee on a single transaction. CPFP requires you to pay enough on the child to subsidize the entire combined size. For a 200-byte parent stuck at low fee, RBF might cost you 5,000 extra sats; CPFP might cost 50,000.

However, RBF is not always available. The decision tree:

• Are you the sender, and is the original transaction RBF-flagged? → Use RBF. It is cheaper.
• Are you the sender, but the transaction is not RBF-flagged? → CPFP using the change output.
• Are you the receiver? → CPFP is your only option. The sender can sometimes still RBF if they flagged it, but you don’t control that.
• Did the transaction spend all outputs externally (no change, you are not the recipient)? → You have no leverage. Wait, or ask the receiver to CPFP.

One subtle gotcha: a small but loud minority of merchants still refuse to accept RBF-flagged payments at the unconfirmed stage because the sender could replace the transaction with a different recipient. This is called “zero-confirmation fraud,” and CPFP-style transactions (which can’t be replaced, only added to) are sometimes preferred by point-of-sale terminals. Mostly this doesn’t matter for normal users, but it is the historical reason CPFP exists alongside RBF rather than being made redundant.

The mistakes to avoid

A few CPFP traps that trip up beginners:

Spending an output you don’t actually own. If a friend sent you 0.01 BTC and the transaction is unconfirmed, you can CPFP that output because the coins are addressed to your wallet. You cannot CPFP someone else’s transaction unless one of its outputs is yours.

Setting a fee rate that is still below the market. The wallet defaults are usually fine. If you manually override them, double-check on a mempool dashboard. A CPFP that is also too low to confirm just creates a second stuck transaction.

Using CPFP when the transaction has been dropped from the mempool. If it has been more than two weeks (Bitcoin Core’s default mempool expiry), the parent transaction may have been forgotten by the network entirely. CPFP cannot resurrect a transaction the network no longer sees. In that case, the original coins return to the sender’s wallet automatically — ask them to resend.

Confusing “unconfirmed” with “lost.” An unconfirmed transaction is not lost. It is queued. CPFP shortens the queue. Worst case, you wait. You don’t lose the coins.

The mental model to remember

Picture the Bitcoin mempool as airport standby. Every transaction is a standby passenger with a budget. Miners are gate agents. They board passengers in descending order of budget per pound (fee per byte). RBF is a passenger walking up and handing the gate agent a bigger budget. CPFP is a relative of the stuck passenger walking up, paying a huge fee, and saying “I will only board if my parent does too.” The gate agent does the math, sees that the combined budget per pound is now attractive, and lets them both on.

Once you have the mental model, the wallet steps are mechanical. The hard part is knowing when CPFP is the right move — and now you do.

Related reading on BitcoinHomeBase

If you want the RBF side of this story, the guide to RBF covers the cheaper-but-pickier option. The mempool explainer covers why transactions queue in the first place. And the network fees guide covers how to set the right fee rate before you broadcast, which is the cheapest fix of all.

The shortest possible summary

1. CPFP unsticks a stuck Bitcoin transaction by spending one of its outputs in a new high-fee transaction.
2. Anyone who owns an output of the parent can do it — sender or receiver.
3. Use it when RBF is not flagged on the parent, or when you are on the receiving side.
4. Sparrow, Electrum, and BlueWallet all support one-click CPFP in 2026.
5. Expect to pay more than you would for RBF, because the child carries the combined fee shortfall.

If you remember nothing else: a stuck Bitcoin transaction is rarely lost. The network has not forgotten it; the miners just have not been paid enough yet. CPFP is the way to fix that from the receiving side.