What is child pays for parent (CPFP)?

A fee trick in which you spend the output of a stuck transaction in a new, high-fee transaction, so a miner must include both to collect the second one's fee.

Miners select transactions by the fee rate of a package rather than of a single transaction, so a generous child effectively subsidizes a starved parent. This is the option when a stuck payment cannot simply be replaced, either because the sender did not signal replace by fee or because you are the receiver and cannot rewrite someone else's transaction.

The catch is cost. You are paying for two transactions instead of one, and the child must carry enough fee to lift the combined rate of both, so it is materially more expensive than a replacement would have been.

How it works

A Bitcoin transaction cannot be confirmed unless every transaction it spends from is confirmed first. That dependency is what makes the trick work: a miner wanting the child's fee has no choice but to include the parent in the same block.

Mining software evaluates ancestor and descendant packages by combined fee divided by combined size, in satoshis per virtual byte. To rescue a parent you compute the fee rate you actually want for the pair, multiply by the total size of both transactions, and set the child's fee to that total minus what the parent already paid.

The receiver can do this as well as the sender, which is the property that makes CPFP genuinely different from replacement. Spending the incoming output, even back to another address you own, drags the parent along.

Node policy caps how large an unconfirmed package can get, so a long chain of unconfirmed transactions cannot be rescued indefinitely by adding one more child.

Example

Illustrative. A parent transaction of 200 virtual bytes paid 2 satoshis per virtual byte, so 400 satoshis, and is stuck. You want the pair confirmed at 20 satoshis per virtual byte. You create a child of 150 virtual bytes spending the parent's output. Combined size is 350 virtual bytes, so the package needs 7,000 satoshis. The parent contributed 400, so the child must pay 6,600 satoshis, a rate of 44 satoshis per virtual byte on its own. Total spend is 7,000 satoshis instead of the 4,000 the parent alone would have cost at 20 satoshis per virtual byte.

Why it matters when you buy

If you withdraw from an exchange during a fee spike and the transaction stalls, you usually cannot replace it, because the exchange signed it. Once the funds land in your wallet as an unconfirmed output, spending that output with a high fee is the tool that gets it confirmed. Fee conditions and withdrawal fee policy differ by venue, which the fee comparison records, and gas fees explained covers the same problem on other chains.

Related terms

replace by fee — the cheaper fix when the sender controls the transaction; sat vb — the unit fee rates are quoted in; mempool — where stuck transactions wait; utxo — the output the child spends; coin control — choosing exactly which output to use.

Questions

Can I use CPFP on a deposit an exchange sent me?

Yes, and this is its main practical use. The exchange controls the parent, but you control the output it paid you, so spending that output at a high fee pulls the deposit in with it.

Is it cheaper than replace-by-fee?

No. Replacement pays for one transaction, CPFP pays for two. Use replacement whenever you sent the transaction and signaled for it, and keep CPFP for cases where replacement is unavailable.

What if the transaction has no change output I control?

Then you cannot do it as the sender. Only a party who controls one of the parent's outputs can create the child, which in a payment usually means the receiver.