Child Pays for Parent (CPFP) Explained
Reviewed and updated September 19, 2026 by the SmartCryptoEarnings editorial team · editorial policy
Child pays for parent, usually written CPFP, is the other way to improve a stuck Bitcoin transaction's prospects. Instead of replacing it, you leave it alone and create a new transaction that spends one of its outputs while paying a generous fee.
It works because a child transaction cannot be mined unless its parent is mined first. A miner assessing the child must therefore consider the pair together — and if the combined fee across the combined size is attractive, including both becomes worthwhile.
- Inputs: coins the sender already controlled
- Output A: the payment to the recipient
- Output B: change back to the sender
Both outputs exist but are unconfirmed. Either one can be the starting point for a child.
- Child built by the recipient (spends Output A)
The recipient spends the payment they have not yet received confirmation of, paying a high fee rate. This is the only fee bump a recipient can drive themselves.
- Child built by the sender (spends Output B)
The sender spends their own change output back to themselves, paying a high fee rate. Useful when the wallet has no replace function.
The child cannot be mined without the parent, so the relevant economics are the combined fee across the combined size. If that is competitive, including both becomes worthwhile. It remains the miner's decision — this is an incentive, not a guarantee.
You pay for two transactions with this approach, and the child must carry the parent's shortfall as well as its own size. Node software also limits how large a group of related unconfirmed transactions it will track, and those limits vary by release.
The mechanism, step by step
- The parent transaction is broadcast and sits unconfirmed because its fee rate is uncompetitive.
- The parent creates outputs — typically the payment to the recipient and a change output back to the sender.
- Someone who controls one of those unconfirmed outputs builds a child transaction that spends it, deliberately setting a high fee.
- Because the child is only valid after the parent, a miner considering the child evaluates the economics of parent and child as a unit rather than the child alone.
- If that combined fee rate is competitive, the miner has an incentive to include both in a block, and the parent confirms alongside its child.
The parent is never modified. Its transaction ID, its outputs and its recipient stay exactly as they were, which is what makes CPFP usable when replacement is not.
Who can use it
- The sender, if the parent created a change output back to their own wallet. Spending that change with a high fee is the usual sender-side CPFP.
- The recipient, if the parent pays them and their wallet lets them spend that still-unconfirmed output. This is the case that matters most: it is the only fee-bumping approach a recipient can drive themselves.
- Neither party, if the parent has no output either of them can spend — for example a payment whose only outputs belong to someone who will not act.
What you need for it to work
- An unspent output of the stuck transaction that you hold the keys for.
- A wallet willing to spend an unconfirmed input at all. Many wallets refuse to show or select unconfirmed coins, which silently rules CPFP out.
- Manual fee-rate control in that wallet, because the child must pay well above the going rate to lift the pair's combined economics.
- Enough value in the output being spent to cover that fee. A tiny output cannot pay a large fee.
The limits worth knowing before you try
- It is not a guarantee. Miners choose what to mine; a favourable package is an incentive, not an instruction.
- You are paying for two transactions. The child's fee has to compensate for the parent's shortfall as well as its own size, so the total cost can exceed what a single correctly priced transaction would have cost.
- Custodial users are usually excluded. If an exchange holds the keys, you cannot build a child transaction against your deposit.
- Nodes limit how large a group of related unconfirmed transactions they will keep. Long chains of unconfirmed transactions can hit those limits, and the specific limits depend on the node software version.
- Historic explanations quoting exact ancestor and descendant counts as universal Bitcoin behaviour are unreliable. Bitcoin Core has been moving from those older ancestor/descendant limits towards a cluster-based model, and the values differ by release — treat the current policy documentation as the reference.
CPFP versus RBF
| Child pays for parent (CPFP) | Replace-by-fee (RBF) | |
|---|---|---|
| What changes | Nothing about the original. A new child transaction is added. | The original is replaced by a conflicting, higher-paying version. |
| Who needs control | Anyone holding an unspent output of the parent — sender or recipient. | Only the sender, who must re-sign the same inputs. |
| When it may apply | Parent unconfirmed and has a spendable output available to you. | Transaction unconfirmed and the sending wallet offers replacement. |
| Wallet support | Must allow spending unconfirmed inputs and setting a custom fee rate. | Must offer a fee bump / replace function. |
| Typical cost | Two transactions' worth of block space. | One transaction, at a higher fee than the original. |
| Main limitation | Needs a spendable output and enough value in it; package limits apply. | Custodial senders cannot offer it; replacement propagation is policy-dependent. |
What CPFP is not
- It is not a way to cancel or redirect the parent. The parent's outputs are fixed.
- It does not work on a confirmed transaction — there is nothing to accelerate.
- It is not a service. Anyone offering to perform CPFP for you in exchange for a payment, a wallet connection or your recovery phrase is running a scam pattern, not a fee bump.
Frequently Asked Questions
What is child pays for parent?
It is creating a new transaction that spends an output of a stuck, unconfirmed transaction and pays a high fee, so that a miner evaluating the two together has an incentive to mine both.
Can the receiver speed up a Bitcoin transaction?
Sometimes, using CPFP. If the payment to them is unconfirmed and their wallet can spend that unconfirmed output with a custom fee, they can build a child transaction. Replacement, by contrast, is only ever available to the sender.
Does CPFP guarantee the parent will confirm?
No. It improves the combined economics of the pair, which makes inclusion more attractive to miners. Transaction selection remains the miner's decision.
Is CPFP cheaper than RBF?
Usually not. CPFP pays for two transactions rather than one, and the child must pay enough to compensate for the parent's low fee rate as well as its own size.
Why will my wallet not let me spend an unconfirmed output?
Many wallets deliberately hide unconfirmed coins, because spending them creates a chain that is only valid if the parent confirms. Without that ability, CPFP is not available in that wallet.
Sources
Spotted something out of date? See our corrections policy and fact-checking policy.
Continue reading
Educational information only. Nothing here is financial, legal or tax advice.