Child-Pays-For-Parent (CPFP)

Child-Pays-For-Parent (CPFP) is a fee-bumping technique that lets the receiver of funds — not just the sender — speed up a slow transaction. The recipient creates a new child transaction that spends an output of the stuck, low-fee parent and attaches a generous fee to that child. Because a miner cannot include the child without also including the parent, the two are economically welded together: the child's fee subsidizes the parent's confirmation.

How miners evaluate the package

Bitcoin's consensus rules require that the transaction creating an output appear in the chain no later than the transaction spending it. Mining software exploits this by scoring transactions as packages: when assembling a block template, it considers the combined fee and combined size of the parent and child together — the ancestor feerate. If the parent alone pays 2 sat/vB into a 20 sat/vB market but the child is heavy enough to lift the pair's blended rate above 20, a profit-maximizing miner pulls both into the block at once. Node mempool policy puts guardrails on this: by default, chains of unconfirmed transactions are limited to 25 ancestors or descendants, which caps how deep a CPFP chain can stack and how much memory a cluster of related transactions can consume.

When to reach for CPFP

CPFP is the tool of choice when you are receiving funds in a transaction someone else broadcast with too small a fee — you cannot edit their transaction, but you can spend its output to you and pay for both. It also works when the sender's wallet did not signal or does not support Replace-By-Fee (RBF), or when the sender wants to avoid changing the original transaction's txid. The trade-off is cost: the child must pay enough to lift the entire package above the prevailing market feerate, so you are buying block space for two transactions when a sender-side replacement would have repriced one. Practical caveats: you can only bump via an output you can spend, and a change output or payment to yourself is the usual handle; if the parent has no output you control, CPFP is off the table.

Where CPFP quietly runs your infrastructure

CPFP is not just a manual rescue tool — it is load-bearing in the Lightning Network. Channel commitment transactions are signed long before anyone knows what feerates will be at close time, so they carry anchor outputs: small outputs each party can spend with a CPFP child to drag the commitment into a block during a contested close. If you run a node, your software is prepared to fee-bump this way at exactly the moment it matters. For a sovereign operator the broader lesson is about fee literacy: confirmation is an auction, and CPFP means either side of a payment can bid. Understanding how packages are priced — and keeping a spendable UTXO handle on incoming funds — is part of operating on mempool terms rather than waiting on someone else's wallet defaults.

Package relay and the sharpening toolset

CPFP has one historical soft spot: it assumed the parent made it into mempools at all. A parent paying below a node's minimum relay feerate could be dropped entirely during congestion, leaving the child an orphan bidding for a transaction nobody held — precisely the failure mode that threatened Lightning force-closes at the worst possible moments. Recent Bitcoin Core releases close this gap with limited package relay, letting a parent and its fee-bumping child be submitted and evaluated together, and with topologically restricted (TRUC) transactions that constrain unconfirmed chains to keep such packages cleanly replaceable. The direction of travel is clear: fee-bumping is being hardened from a clever trick into guaranteed plumbing, because contested Lightning closes depend on it working under adversarial conditions. For an operator the takeaway is to keep node software current — the reliability of your own fee bumps is quietly improving underneath you.