Child-Pays-For-Parent (CPFP) Explained

Child-Pays-For-Parent (CPFP) is a Bitcoin fee-bumping technique where a new "child" transaction spends an output from an unconfirmed "parent" transaction and attaches a high enough fee to make the two transactions attractive to miners as a combined package, effectively pulling the stuck parent along with it into a block.

How CPFP works

Miners don't evaluate transactions purely in isolation when deciding what to include in a block — most modern mining software evaluates dependent chains of unconfirmed transactions together, calculating an effective combined fee rate for the whole package. If a low-fee parent transaction has a child transaction spending one of its outputs, and that child pays an unusually high fee, the combined average fee rate for parent-plus-child can be attractive enough for a miner to include both in the same block, even though the parent alone wasn't paying enough.

In practice, this means:

1. A transaction (the "parent") is broadcast with too low a fee and gets stuck in the mempool, as described in /blog/what-is-the-bitcoin-mempool.
2. Someone who controls one of the parent's outputs — either the original sender's change output, or a recipient's newly received funds — creates a new transaction (the "child") spending that output.
3. The child transaction includes a high fee, high enough that the average fee rate across both transactions clears the going market rate.
4. Miners, evaluating the package together, include both transactions in the same block.

Who can use CPFP

This is the key distinction from Replace-By-Fee, covered in our companion article /blog/replace-by-fee-rbf-explained: CPFP can be initiated by either party, not just the original sender. If you receive a Bitcoin payment that's stuck because the sender used too low a fee, you can create a child transaction spending your newly received (but unconfirmed) output, and pay a high fee yourself to get the whole package confirmed. RBF, by contrast, requires the sender to be the one to act, since only they control the original transaction's inputs.

This makes CPFP especially useful for recipients — merchants, exchanges, or individuals — who are waiting on an incoming payment that appears underpriced and want to get it confirmed at their own expense, rather than waiting on the original sender to fix it (who may be unreachable, or simply may not bother).

RBF versus CPFP at a glance

Scenario	Better tool
You sent a transaction with too low a fee	RBF (if flagged as replaceable)
You received a stuck payment and want it confirmed faster	CPFP
The original transaction didn't signal RBF support	CPFP is your only fee-bump option
You want to change the destination address of a stuck send	RBF (since it replaces the transaction entirely)
You want to avoid touching the original transaction at all	CPFP (it leaves the parent untouched, just adds a child)

A practical example

Imagine you run a small business and a customer sends you bitcoin with a fee that turns out to be too low during a period of network congestion. You don't control their wallet, so RBF isn't available to you. Instead, you can spend the unconfirmed output you received (many wallets support "spend unconfirmed funds" for this purpose) in a new transaction — perhaps consolidating it with other funds, or sending it onward — and attach a high fee. Miners see that confirming your child transaction requires confirming the customer's parent transaction too, and if the combined package fee rate is attractive, both get included together.

Costs and trade-offs

CPFP isn't free. Because you're paying for both your child transaction's own byte size and effectively subsidizing the parent's stuck fee, the total cost of a CPFP rescue is often higher than if the original sender had simply estimated their fee correctly, using the guidance in /blog/how-bitcoin-transaction-fees-work. It's a reactive tool, not a substitute for good fee estimation practices, which we cover more broadly in /blog/how-to-reduce-bitcoin-transaction-fees.

There's also a technical limitation: your child transaction typically needs a confirmed or otherwise usable output to spend from the parent. If the parent transaction hasn't propagated to enough of the network, or your wallet doesn't support spending unconfirmed outputs, CPFP may not be available to you in every wallet.

Why this matters beyond individual transactions

CPFP reflects a broader truth about Bitcoin's fee market: miners aren't just picking the single highest-fee transaction each time, they're optimizing across dependency chains to maximize total fee revenue per block. This package-relay approach has become increasingly sophisticated in node and mining software over time, and it's part of why fee estimation, discussed at length in /blog/how-bitcoin-transaction-fees-work, isn't always a perfectly simple, isolated calculation.

For anyone managing Bitcoin as part of a broader portfolio alongside DeFi or other crypto activity, understanding these settlement mechanics matters just as much as understanding topics like /glossary/gas or /glossary/liquidation on other chains — the underlying idea of "paying for priority" recurs across the wider crypto ecosystem, even though the specific mechanics differ.

Bottom line

CPFP lets whoever controls an output of a stuck transaction — sender or receiver — pay a high fee on a follow-up transaction to pull the whole package into a block. It's the go-to fix when you've received an underpriced payment and can't rely on the sender to bump it themselves, complementing RBF as one of the two main tools for rescuing stuck Bitcoin transactions.