CPFP works by spending the output of a stuck transaction in a new transaction that pays generously. Miners score parent and child together as a package, so a well funded child drags its underpriced parent into a block. It is the standard fix for anyone who received a slow payment and cannot replace it.
Replace-By-Fee solves the sender's problem. It does nothing for the person on the other end, who is watching a payment crawl and has no ability to re-sign somebody else's transaction.
Child Pays For Parent is the answer to that, and it works because of a detail in how miners choose transactions that is worth understanding before you use it.
Why it works at all
A miner filling a block wants the most fee revenue per byte. If it looked at transactions one at a time, an unconfirmed transaction paying 0.2 sat/vB would simply be skipped.
But transactions are linked. If transaction B spends an output of transaction A, then B cannot be mined without A. A miner that wants B's generous fee has to take A along with it.
So miners evaluate them together. They compute the combined fee divided by the combined size, and use that package rate to decide. A child paying well can lift a parent that would never have been chosen alone.
The one sentence version
You are not raising the parent's fee. You are creating a new transaction whose fee is generous enough to pay for both, and letting the miner do the arithmetic.
Who needs it
- You received a payment that was sent at too low a fee. The classic case.
- You sent a payment and your wallet cannot do RBF, but you have a change output you can spend.
- Your transaction has an unconfirmed parent that is the real bottleneck, so bumping your own would achieve nothing.
- You withdrew from an exchange that will not bump its own transaction. Covered in the exchange guide.
The requirement is that you can spend one of the stuck transaction's outputs. If you received the payment, you can, and that is the whole prerequisite.
Working out the child fee
This is where people get it wrong, usually by paying far too much. The target is a package rate, not a child rate.
The formula
Take the combined fee of parent and child, divide by their combined size, and that is what the miner sees. To reach a target rate you need:
child fee = (parent size + child size) × target rate − parent fee
A worked example
Parent stuck at 0.2 sat/vB
- Parent: 250 vB, paid 50 sats, so 0.2 sat/vB
- Child: roughly 110 vB for a simple one input one output spend
- Combined size: 360 vB
- Target rate: 1.5 sat/vB
- Fee needed across both: 360 × 1.5 = 540 sats
- Already paid by the parent: 50 sats
- Child must pay: 490 sats, which is about 4.5 sat/vB on the child alone
Notice the child's own rate looks alarmingly high at 4.5 sat/vB. That is expected and correct. The child is small, so it has to carry a disproportionate share to lift the average. Do not let the number scare you into overpaying further.
Skip the arithmetic
Paste the transaction ID and we compute the effective package rate, the target, and what a child would need to pay.
Doing it in each wallet
Electrum
Right click the incoming unconfirmed transaction and choose Child pays for parent. Electrum works out the child fee itself, taking the parent into account, and shows the resulting package rate. This is the smoothest implementation of the three.
Sparrow
In the Transactions tab, right click the unconfirmed incoming transaction and use the CPFP option. Sparrow shows both the child fee and the effective package rate before you sign, which makes it easy to check you are not overpaying.
Bitcoin Core
There is no one click option. Send a transaction that explicitly spends the unconfirmed output back to yourself, setting the fee manually from the formula above. Coin control is required so you can select that specific unconfirmed output as the input.
Anywhere else
Any wallet with coin control can do CPFP even without naming the feature. Create a payment to yourself, select the unconfirmed incoming output as the only input, and set a high enough fee. That is all CPFP is.
What changed in Bitcoin Core 31
Cluster mempool arrived in Core 31.0 in April 2026 and it changed the rules that most CPFP guides still describe.
The old system limited how many unconfirmed ancestors and descendants a transaction could have, 25 of each, and included a special carve-out allowing one extra small child specifically so CPFP would keep working in tight spots.
The new system groups connected transactions into clusters and limits each cluster to 64 transactions and 101 kvB. Transactions are ordered by the expected mining rate of whole chunks rather than individually, which makes package evaluation more accurate. The CPFP carve-out has been removed, because the new ordering makes it unnecessary.
What this means in practice
For a normal CPFP on a single stuck payment, nothing changes and it works as before. If you are dealing with a long chain of unconfirmed transactions, the limits behave differently and a child can be rejected for cluster reasons that did not exist under the old rules.
When CPFP fails
- The output is dust. If the amount you received is tiny, spending it may cost more in fees than it is worth.
- You do not control any output. If the payment went to somebody else entirely, you have no lever.
- The cluster is full. Long chains of unconfirmed spends can hit the 64 transaction limit.
- The parent was dropped. If it expired out of mempools there is nothing to attach to. See the guide on vanished transactions.
- Your wallet cannot select the unconfirmed output. Without coin control you cannot force it to spend that specific input.
CPFP against RBF
Where both are available, RBF is usually better. It produces one transaction instead of two, so you pay for less total block space.
| Situation | Tool | Reason |
|---|---|---|
| You sent it and can re-sign | RBF | One transaction, cheaper overall |
| You received it | CPFP | You cannot re-sign another person's transaction |
| Unconfirmed parent is the bottleneck | CPFP | Lifts the whole package at once |
| Wallet has no bump button | CPFP | Any wallet with coin control can do it |
| Exchange withdrawal | CPFP | Only the exchange could replace it |
A full comparison sits in the RBF guide, including what a bump costs at each transaction size.
Doing it without overpaying
- Find the real package rate first. If the parent already has other unconfirmed relatives, they count too.
- Target just above the clearing rate, not far above it.
- Keep the child small. One input and one output. Every extra byte raises the fee needed.
- Send it to yourself. The child exists to carry a fee, not to move value anywhere.
- Check the result on an explorer that shows effective fee rate rather than the naive one.
The bottom line
CPFP is the tool for anyone who cannot replace a transaction, which mainly means receivers and people waiting on exchange withdrawals. It costs a little more than RBF because you pay for two transactions instead of one, and it still costs a fraction of what a paid accelerator quotes for the same job.
Work out the child fee
We show the package rate including every unconfirmed ancestor, and what the child needs to pay to clear the next block.
Frequently asked questions
What is Child Pays For Parent?
CPFP is a way to speed up a stuck Bitcoin transaction by spending one of its outputs in a new transaction that pays a high fee. Miners evaluate parent and child together as a package, using the combined fee divided by the combined size, so a generous child pulls an underpriced parent into a block with it.
When should I use CPFP instead of RBF?
Use CPFP when you cannot replace the transaction, which mainly means you received the payment rather than sent it, or it came from an exchange that signed it. Use RBF when you sent the transaction and your wallet exposes a fee bump, because it produces one transaction instead of two and costs less overall.
How do I calculate the child fee for CPFP?
Multiply the combined size of parent and child by your target fee rate, then subtract what the parent already paid. For a 250 vB parent that paid 50 sats, with a 110 vB child targeting 1.5 sat/vB, the child needs 360 times 1.5 minus 50, which is 490 satoshis.
Why does the child transaction need such a high fee rate?
Because the child is small and has to lift the average for the whole package. A child paying 4.5 sat/vB on its own can be exactly right for bringing a package to 1.5 sat/vB. The number that matters is the package rate, not the child's own rate.
What changed for CPFP in Bitcoin Core 31?
Core 31.0 replaced the old ancestor and descendant limits with cluster mempool, which caps connected groups at 64 transactions and 101 kvB and orders transactions by the mining rate of whole chunks. The old CPFP carve-out that allowed one extra child was removed because the new ordering makes it unnecessary.
Can CPFP fail?
Yes. It fails if the output you would spend is dust and not worth spending, if you control no output of the stuck transaction, if the cluster limit is already reached, if the parent has been dropped from mempools entirely, or if your wallet cannot select the specific unconfirmed output as an input.