How Child-Pays-for-Parent (CPFP) works in Bitcoin - package relay mechanics, fee calculation, use cases for recipients and senders, comparison with RBF, and practical wallet examples.
You are waiting to receive a Bitcoin payment. The sender set the fee too low, and the transaction has been sitting unconfirmed in the mempool for hours. You cannot use RBF because only the sender can replace a transaction. But you are not powerless. You can spend the unconfirmed output you are about to receive, attaching a fee high enough to make miners want to confirm both transactions together. This technique is called Child Pays for Parent (CPFP).
CPFP is the complement to RBF. Where RBF lets a sender replace their own stuck transaction, CPFP lets anyone with a spendable output - including the recipient - accelerate confirmation. Together, they form the two primary tools for fixing stuck Bitcoin transactions.
The mechanics of CPFP are rooted in how miners select transactions for blocks. Miners do not evaluate transactions in isolation - they evaluate transaction packages. If a low-fee parent transaction has a high-fee child transaction that depends on it, a rational miner will include both, because the combined fee rate of the package exceeds what they would earn from alternative transactions.
Here is the sequence:
The parent must be confirmed before the child can be valid on-chain, because the child spends an output that does not exist until the parent is confirmed. This dependency is what forces miners to include the parent.
The child transaction must compensate for the parent's fee shortfall. The formula:
target_package_fee = desired_rate × (parent_vsize + child_vsize)
required_child_fee = target_package_fee - parent_fee
child_fee_rate = required_child_fee / child_vsize| Parameter | Value |
|---|---|
| Parent virtual size | 225 vB |
| Parent fee | 450 sats (2 sat/vB) |
| Child virtual size | 141 vB |
| Desired package rate | 12 sat/vB |
target_package_fee = 12 × (225 + 141) = 4,392 sats
required_child_fee = 4,392 - 450 = 3,942 sats
child_fee_rate = 3,942 / 141 ≈ 28 sat/vBThe child must pay approximately 28 sat/vB to bring the entire package up to 12 sat/vB. This is significantly higher than the target rate, because the child is compensating for the parent's underpayment.
Recipients - This is CPFP's primary advantage over RBF. If someone sent you bitcoin with a low fee, you can spend that unconfirmed output with a high-fee child transaction. You do not need the sender's cooperation.
Senders - If your transaction has a change output returning funds to your own wallet, you can spend that change output as a CPFP child. This is useful when RBF was not signaled on the original transaction.
Anyone with a spendable output - In transactions with multiple outputs, any output owner can create a child. In multi-party protocols like CoinJoin or Lightning channel closes, any participant with a spendable output can use CPFP.
Right-click an unconfirmed incoming transaction → "Accelerate Transaction (CPFP)". Sparrow automatically calculates the required child fee and creates the transaction.
Spend the unconfirmed UTXO to yourself with an elevated fee:
bitcoin-cli -named sendtoaddress \
address="your-address" \
amount=0.0009 \
fee_rate=30 \
include_unsafe=trueThe include_unsafe=true flag allows spending unconfirmed outputs.
In the History tab, right-click the unconfirmed transaction → "Child pays for parent." Electrum handles the fee calculation automatically.
| CPFP | RBF | |
|---|---|---|
| Who can use it | Sender or recipient | Sender only |
| Mechanism | New child transaction | Replacement transaction |
| Requires signaling | No | Yes (opt-in RBF) or full RBF |
| Creates new TXID | Yes (child has its own TXID) | Yes (replacement gets new TXID) |
| Parent TXID changes | No - parent TXID stays the same | Yes - original TXID is invalidated |
| Cost efficiency | Lower (pays for child TX overhead) | Higher (single TX, no overhead) |
| Best for | Recipients, non-RBF transactions | Senders with RBF-enabled wallets |
A critical difference: with CPFP, the original parent TXID remains valid. The recipient's TXID does not change. With RBF, the original TXID is invalidated and replaced with a new one. This matters for merchants and payment processors that track transactions by TXID.
CPFP relies on miners evaluating transactions as packages rather than individually. This is implemented through Bitcoin Core's ancestor fee rate calculation:
When selecting transactions for a block template, Bitcoin Core calculates each transaction's ancestor fee rate - the total fee of the transaction plus all its unconfirmed ancestors, divided by their combined virtual size. Transactions are sorted by ancestor fee rate, ensuring that profitable packages are included together.
For a child transaction to be accepted into the mempool, the parent must already be in the mempool (or submitted simultaneously via package relay). Bitcoin Core enforces limits on ancestor and descendant chains:
These limits prevent denial-of-service attacks through excessively long transaction chains while still allowing practical CPFP usage.
Historically, CPFP had a chicken-and-egg problem: if the parent's fee rate was below the mempool minimum, nodes would reject the parent before the child could be submitted. Package relay (implemented progressively in Bitcoin Core) solves this by allowing parent and child to be submitted as a single package, evaluated together.
This is particularly important for Lightning Network force-close transactions, which may have pre-signed fees that become insufficient during fee spikes.
CPFP plays a critical role in Lightning Network security. When a channel is force-closed, the commitment transaction is broadcast with a fee that was set when the channel was last updated - potentially days or weeks earlier. If fees have risen since then, the commitment transaction may be stuck.
Lightning implementations use anchor outputs - small outputs specifically designed to be spent via CPFP. Each party in the channel gets an anchor output they can use to bump the commitment transaction's effective fee rate. This ensures that channel closes can always confirm in a timely manner, even during fee spikes.