Bitcoin child-pays-for-parent, usually shortened to CPFP, is a fee-bumping method for an unconfirmed transaction. Instead of replacing the original transaction, a wallet spends one of its unconfirmed outputs in a new child transaction and gives that child a high fee.
Miners can then evaluate the parent and child together. If the combined fee rate is attractive enough, including the child requires including its parent first, so the child can improve the package’s chance of confirmation.
Documentation check: This guide follows Bitcoin Core’s CPFP and package-policy documentation reviewed on 24 October 2026. Wallet support and mempool policy can differ between software and nodes.
The short version
A Bitcoin transaction cannot confirm after a transaction that spends one of its outputs. That order creates the leverage CPFP uses:
- the parent transaction creates an unconfirmed output;
- the recipient or sender controls that output;
- a child transaction spends it;
- the child pays enough fee to make the parent-plus-child package competitive;
- a miner that wants the child must confirm the parent before it.
CPFP does not edit the parent’s fee. It adds another transaction whose fee can lift the package’s average fee rate.
Why the combined fee rate matters
Bitcoin fees are usually compared by fee rate, not by the amount of bitcoin being moved. The relevant size is measured in virtual bytes, and a package contains the virtual sizes and fees of both transactions.
A simplified calculation is:
package fee rate =
(parent fee + child fee) /
(parent virtual size + child virtual size)
Suppose a 200-vbyte parent paid 400 satoshis, or 2 sat/vB. A 150-vbyte child paying 3,800 satoshis would make the two-transaction package 350 vbytes with 4,200 satoshis in total, or 12 sat/vB.
That example explains the arithmetic, not a recommendation. A useful target depends on the current mempool and the node or miner evaluating the package. Wallets may estimate the fee for you, but the result is still an estimate.
For the underlying size calculation, read Does a Bitcoin Fee Depend on the Amount Sent?.
Who can create the child
The child must spend an output from the unconfirmed parent. That usually means one of two parties can use CPFP:
- the recipient, if the parent created an output to a wallet they control;
- the sender, if the parent created an unconfirmed change output back to their wallet.
A person who controls no output from the parent cannot simply attach a fee to it. Some wallets hide unconfirmed outputs by default, and some will not let a user spend them manually. In that case, the protocol may allow CPFP while the selected wallet does not expose the option.
Using an unconfirmed change output also has a practical risk: the child can create another dependency while the parent is still unsettled. A wallet should show which output it will spend and calculate the fee for the complete package.
CPFP is different from replace-by-fee
Replace-by-fee, or RBF, creates a replacement for an unconfirmed transaction. CPFP keeps the original transaction and adds a dependent child.
| Question | RBF | CPFP |
|---|---|---|
| What changes? | The original transaction is replaced | A new child spends an original output |
| Who normally acts? | A sender or wallet able to replace the original | Whoever controls a spendable parent output |
| How is the incentive raised? | The replacement pays more | The package’s combined fee rate rises |
| Is there another transaction? | Replacement takes the original’s place | Parent and child both remain |
| Main wallet requirement | Replacement support and suitable signaling/policy | Ability to spend the unconfirmed output |
The mechanisms can meet different needs. A sender may prefer RBF when the wallet created the transaction with replacement support. A recipient who controls an output but cannot replace the parent may use CPFP instead. See Bitcoin Replace-by-Fee for the replacement path.
What miners and nodes evaluate
The Bitcoin Developer Glossary defines ancestor mining as selecting transactions based not only on their own fees, but also on the fees of ancestors and descendants. CPFP depends on this package view.
Bitcoin Core 26.0 added the experimental submitpackage RPC. Its release notes describe package CPFP as allowing a high-fee child to help a parent that sits below the mempool minimum fee rate, while also noting an important boundary: the parent still cannot be below the minimum relay fee rate. The release notes warned that successful local submission did not guarantee propagation because package relay was not supported at that stage.
Current Bitcoin Core 30.0 RPC documentation still describes submitpackage as experimental and says a package is checked against consensus and mempool policy. That distinction matters:
- consensus rules decide whether transactions could be valid in a block;
- mempool policy decides whether a node accepts or relays them before confirmation;
- mining policy decides which accepted transactions a miner selects.
A valid parent and child can therefore receive different treatment across nodes. CPFP improves the economic incentive; it does not force universal relay or inclusion.
Why a high child fee may still fail
Several conditions can prevent the expected result.
The parent is not accepted
A child cannot rescue a parent that is invalid. Package handling also has policy limits. Bitcoin Core’s package submission documentation tells operators to consult its package-policy rules, and wallet behavior may lag behind node capabilities.
The output cannot be spent yet
The wallet may not expose the unconfirmed output, may mark it unavailable, or may lack the key needed to spend it. A timelock or script condition can also prevent an immediate child spend.
The package remains uncompetitive
The child’s fee may look high on its own but still be too small when averaged across the parent and child sizes. A very large low-fee parent needs a larger child fee to reach the same package rate.
Another dependency changes the package
If the child also spends other unconfirmed inputs, the effective package can include more ancestors than expected. Wallets should calculate the complete dependency set rather than only two visible transactions.
Confirmation is never guaranteed
Miners choose their own transaction policies and block templates. Network congestion can change after the child is broadcast. A competitive fee rate improves probability, not certainty.
A safe wallet flow
A wallet offering CPFP should make the package visible before asking for approval. A useful confirmation screen shows:
- the parent transaction ID and its confirmation state;
- the specific unconfirmed output being spent;
- the parent’s fee, size and fee rate;
- the child’s proposed fee and size;
- the combined package fee rate;
- the value that will remain after the child fee;
- whether other unconfirmed ancestors are involved;
- a warning that broadcast does not guarantee confirmation.
The wallet should also prevent accidental fee overpayment. If the child output is small, an aggressive fee target can consume a large share of it. Showing only “speed up” without the actual satoshi amount hides the most important tradeoff.
When to wait instead
CPFP is not always the sensible next action. Waiting may be better when the parent already has a competitive fee rate, congestion is falling, the payment is not urgent, or the available output is too small to create a reasonable child.
Before taking action, check that the transaction really remains unconfirmed and has not simply disappeared from one wallet’s view. Compare the transaction ID in more than one reliable source, check whether the parent is still accepted by your wallet’s node, and confirm that the planned child spends the intended output.
For what confirmation counts do and do not mean, read Bitcoin Confirmations: What 1, 3 and 6 Blocks Mean.
