Child-Pays-for-Parent (CPFP)

What Is Child-Pays-for-Parent?

Child-Pays-for-Parent (CPFP) is a Bitcoin fee-bumping technique that allows a recipient to accelerate the confirmation of an unconfirmed transaction. The recipient creates a new "child" transaction that spends one of the unconfirmed "parent" transaction's outputs and attaches a fee high enough to cover the deficit of both transactions combined. Miners, who optimize for total revenue per block, are incentivized to include the parent alongside the child because the child's output cannot exist without the parent being confirmed first.

Unlike Replace-by-Fee (RBF), which allows the sender to replace a transaction with a higher-fee version, CPFP gives the receiver the ability to accelerate confirmation. This distinction matters in protocols where the sender may be uncooperative or offline: the receiver can unilaterally push the transaction through by paying the additional fee from their own funds.

CPFP has been supported by Bitcoin Core's mempool logic since version 0.13.0 (2016), which introduced ancestor and descendant package tracking. Modern mining software evaluates transaction "packages" rather than individual transactions when assembling blocks, making CPFP a reliable technique across the network.

How It Works

To understand CPFP, consider how miners select transactions for inclusion in a block. Miners want to maximize the total fees collected within the block's weight limit. When a transaction has unconfirmed parents, the miner must include those parents to make the child valid. The miner therefore evaluates the combined fee rate of the entire ancestor package.

1. A parent transaction is broadcast with a fee rate too low for timely confirmation (for example, 2 sat/vB when the mempool minimum is 10 sat/vB)
2. The recipient identifies a spendable output from the parent transaction in the UTXO set (even though it is still unconfirmed)
3. The recipient constructs a child transaction spending that output, setting a fee high enough to raise the combined package fee rate above the current mempool threshold
4. Mining software evaluates the parent and child together, sees the combined fee rate is now attractive, and includes both in the next block

The Fee Math

The critical calculation is the effective fee rate of the package. Miners consider the aggregate fees divided by the aggregate weight:

effective_fee_rate = (parent_fee + child_fee) / (parent_weight + child_weight)

Example:
  Parent: 250 vB, 500 sats fee (2 sat/vB)
  Target: 15 sat/vB

  Required package fee = 15 * (250 + child_weight)

  If child is 150 vB:
    Required total fee = 15 * (250 + 150) = 6,000 sats
    Child fee needed   = 6,000 - 500 = 5,500 sats
    Child fee rate      = 5,500 / 150 = ~36.7 sat/vB

  The child pays ~36.7 sat/vB so the package averages 15 sat/vB.

The child transaction must pay a disproportionately high fee rate to compensate for the parent's low fee. The smaller the child transaction relative to the parent, the higher the child's individual fee rate must be. This is why keeping child transactions compact matters: a large child dilutes its own fee contribution across more weight.

Mempool Package Limits

Bitcoin Core enforces limits on ancestor and descendant chains to prevent denial-of-service attacks on the mempool. By default:

• Maximum ancestor count: 25 transactions
• Maximum ancestor size: 101 kvB
• Maximum descendant count: 25 transactions
• Maximum descendant size: 101 kvB

If a parent transaction already has many descendants, adding another CPFP child may be rejected by nodes. This is particularly relevant for high-traffic protocols that generate chains of unconfirmed transactions. For a deeper look at how fees and mempool dynamics interact, see the research article on Bitcoin fee market dynamics.

CPFP vs Replace-by-Fee

Both CPFP and RBF solve the same problem (accelerating unconfirmed transactions) but from different perspectives:

In practice, many protocols use both techniques together. The sender may attempt RBF first, with CPFP as a fallback for the receiver if the sender becomes unavailable.

Use Cases

Lightning Network Anchor Outputs

The most critical use of CPFP in modern Bitcoin is in the Lightning Network's anchor output protocol. When a Lightning channel must be closed unilaterally, the commitment transaction is broadcast with a minimal fee. Each party has a dedicated anchor output: a small SegWit output specifically designed to be spent via CPFP.

This design separates fee commitment from channel state. Older commitment transaction formats locked in fees at the time of signing, which created problems: fees set weeks ago might be wildly inaccurate at broadcast time. Anchor outputs let each party independently fee-bump at broadcast time using current fee estimates, as described in the payment channels deep dive.

Ephemeral Dust and Zero-Fee Parents

Ephemeral dust is an extension of the anchor output concept that allows transactions to include outputs below the dust threshold, provided they are spent in the same block. Combined with zero-fee parent transactions, this enables a clean CPFP workflow: the parent transaction pays zero fee and includes a dust anchor, while the child spends that anchor and pays the entire package fee. This eliminates the guesswork of setting any fee on the parent at all.

Receiving Stuck Payments

When someone sends you Bitcoin with too low a fee, CPFP is often your only option. The sender may be an exchange with no support for fee bumping, or an automated system that cannot be easily modified. As the recipient, you can spend the incoming output with a high-fee child to pull the parent into a block. This is a common pattern for businesses processing many incoming payments during fee spikes.

PSBT Workflows

Partially Signed Bitcoin Transactions (PSBTs) can be used to construct CPFP transactions collaboratively. In multi-party protocols, one participant may prepare the child transaction as a PSBT, pass it to the holder of the relevant keys for signing, and broadcast the result. This is particularly useful in custody setups where fee bumping requires coordination between multiple signers.

The CPFP Carve-Out Rule

Standard mempool package limits create a problem for two-party protocols like Lightning. If one party can fill up the descendant limit with their own low-fee children, the other party cannot add a CPFP child: the mempool rejects it for exceeding the descendant count.

To address this, Bitcoin Core introduced the CPFP carve-out rule (also called the anchor carve-out). This rule allows one additional child transaction beyond the normal descendant limit, provided:

• The child has exactly one unconfirmed ancestor (the parent)
• The child is no larger than 10,000 vB
• The child would be the only transaction exceeding the limit

This ensures that in a two-party protocol, each party can always attach at least one CPFP child, even if the counterparty has already attached descendants. The carve-out is specifically designed for Lightning's anchor output pattern, where both channel participants need guaranteed CPFP capability during force closes.

Risks and Considerations

Requires a Spendable Output

CPFP only works if the parent transaction has an output you can spend. If you are the sender and the transaction has no change output returning to your wallet, you cannot CPFP it from the sender side. Similarly, if the recipient's output requires complex spending conditions (such as a timelock that hasn't expired), they may not be able to construct a valid child transaction immediately.

Block Weight Overhead

Unlike RBF, CPFP adds a new transaction to the block. Both the parent and child consume block weight, which means CPFP is inherently less space-efficient than RBF. In high-fee environments, this overhead translates to higher total costs: you pay fees for the child's weight on top of bumping the parent.

Package Relay Limitations

For CPFP to work, the parent transaction must be in the mempool (or submitted alongside the child). If the parent's fee rate is below the mempool minimum, nodes may reject the parent before ever seeing the child. Package relay (BIP 331) aims to solve this by allowing nodes to evaluate parent and child together at submission time, but full deployment across the network is still ongoing.

Until package relay is universally supported, very low-fee or zero-fee parents may not propagate reliably. This is particularly relevant for anchor output protocols that depend on zero-fee commitment transactions.

Pinning Attacks

Transaction pinning is a class of attacks where an adversary makes it difficult or expensive for a victim to CPFP their transaction. The attacker may attach a large, low-fee descendant chain to the parent, consuming the descendant limit and blocking the victim's CPFP attempt. While the carve-out rule mitigates the simplest form of this attack for two-party protocols, more sophisticated pinning vectors remain an active area of fee market research.

Not All Mining Software Supports Package Evaluation

While Bitcoin Core and most major mining pools support ancestor package evaluation, not all mining software is guaranteed to implement it identically. In rare cases, a miner using custom transaction selection logic might not evaluate CPFP packages optimally, though this is increasingly uncommon as the ecosystem standardizes.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.