What Is Child Pays for Parent (CPFP)?

Introduction

Child Pays for Parent (CPFP) is a Bitcoin fee-bumping technique that lets a low-fee unconfirmed transaction become worth confirming by attaching a new, higher-fee transaction that spends one of its outputs. The idea matters because Bitcoin does not confirm transactions in isolation. Transactions can depend on earlier unconfirmed transactions, and miners often make more money by evaluating those dependencies as a package rather than judging each transaction one by one.

That creates a useful puzzle. If a parent transaction is stuck because its fee is too low, why would anyone ever mine it? On its own, they often would not. But if there is a child transaction that can only be mined together with that parent, and the child pays a large enough fee, then the miner’s real choice is not “mine the parent or ignore it.” The real choice is “mine the whole package or leave money on the table.” CPFP is the technique built around that shift in perspective.

In practice, CPFP sits at the intersection of three different layers of Bitcoin behavior. There is the consensus rule that a transaction must appear before any transaction that spends its outputs, so a child cannot be confirmed before its parent. There is the mempool policy used by nodes to decide what unconfirmed transactions they will accept and relay. And there is miner block assembly, where mining software chooses which transactions or transaction packages actually go into a block. CPFP only makes sense when those three layers line up enough for the package to propagate and become economically attractive to miners.

How can a high-fee child make miners accept a low-fee parent?

The simplest way to understand CPFP is to start from first principles. A Bitcoin transaction does not spend an account balance. It spends specific outputs created by earlier transactions. If transaction C spends an output created by transaction P, then P is the parent and C is the child. If P is still unconfirmed, then C depends on P being confirmed first.

That dependency changes the fee calculation miners care about. Suppose the parent is 200 virtual bytes and pays 200 satoshis, so its feerate is 1 sat/vB. In a busy mempool, that may be far too low to get mined soon. Now suppose someone creates a child transaction that is 150 virtual bytes and pays 7,350 satoshis, or 49 sat/vB. The miner cannot include the child alone, because the child spends an output that does not yet exist on-chain. But the miner can include both together. The combined package is 350 virtual bytes with total fees of 7,550 satoshis, for an effective package feerate of about 21.6 sat/vB. If that package feerate is competitive, mining both is rational even though the parent by itself looked unattractive.

That is the compression point for CPFP: the child does not rescue the parent by changing the parent; it rescues the parent by changing the economics of the only valid bundle miners can include.

This is why CPFP is often described as a fee-bump, but it is a different kind of fee-bump from Replace-By-Fee. With RBF, you replace the original transaction with a new version that pays more. With CPFP, you leave the original transaction alone and add a dependent transaction whose fee changes the economics of confirming the pair. The distinction matters because sometimes you cannot replace the original transaction at all, but you can spend one of its outputs.

Why does Bitcoin's ordering rules enable CPFP?

CPFP depends on a basic ordering rule in Bitcoin. If one transaction creates an output and another spends it, the creating transaction must appear earlier in the blockchain than the spending transaction. That ordering can happen across different blocks, or within the same block, but the parent must come first.

This sounds restrictive, and it is. A child cannot magically leapfrog its parent. But that same restriction is what makes CPFP possible. Because miners know they must include parent and child together if they want the child’s fee, they have an incentive to evaluate their combined value. The ordering rule forces the package to move as a unit for Confirmations purposes.

A useful analogy is a two-piece shipment where the second crate contains a reward for delivering both crates, but the reward can only be opened if the first crate arrives first. That analogy explains the economic coupling. Where it fails is that Bitcoin is stricter than shipping logistics: the child is not merely associated with the parent; it is cryptographically invalid to confirm the child first.

Example: how CPFP unblocks a stuck Bitcoin transaction

Imagine Alice sends Bob bitcoin, but uses too low a fee because network demand suddenly rises. The transaction reaches nodes, remains valid, and sits in mempools, but miners are not especially interested. Bob sees the incoming unconfirmed payment, and one of its outputs pays to an address he controls. Bob now has a choice: he can wait, or he can create a new transaction spending that unconfirmed output to himself with a much higher fee.

Nothing about Alice’s original transaction changes. Its txid stays the same. Its low fee stays low. What changes is that there is now a second transaction whose confirmation is impossible unless Alice’s transaction is also confirmed. A miner assembling a block sees that if it includes only Alice’s parent transaction, revenue is poor; if it includes neither, revenue is zero; but if it includes both in the correct order, the average fee over the whole package may beat competing transactions. So the miner adds the parent and child together.

This is why CPFP can be initiated by different parties depending on who controls a spendable output. The recipient can do it if they control the received output. The sender can do it if the original transaction created a change output they still control. Wallet software such as Electrum exposes this directly: for an unconfirmed transaction, it can create a “child pays for parent” transaction, let the user choose a fee, then sign and broadcast the child.

The mechanism is simple, but the operational requirement is not negotiable: someone must control an output of the unconfirmed parent and be willing to spend it immediately. If there is no spendable output under your control, CPFP is not available to you.

How do miners and nodes evaluate parent+child packages?

At a high level, CPFP works because Bitcoin Core and similar software learned to reason about packages instead of isolated transactions. In Bitcoin Core’s mining logic, transaction selection was changed to use a form of feerate with ancestors. In plain language, that means a candidate transaction can be evaluated together with its unconfirmed ancestors, rather than pretending those ancestors are irrelevant.

The selection heuristic is not “find the mathematically perfect set of transactions in the entire mempool.” That global optimization problem is hard. The implemented approach is more practical: consider a high-value transaction together with the unconfirmed transactions required to make it valid, evaluate that package’s effective feerate, and add it if it makes sense. Bitcoin Core developers described this change when ancestor-feerate mining was introduced, and it became part of the 0.13.0 release line. The result was not a new consensus rule. It was a better miner-side policy for earning fees.

That distinction is easy to miss. **CPFP is not guaranteed by consensus in the way signature verification is guaranteed by consensus. ** Consensus only says that if both transactions are included, the ordering must be parent before child and both must be otherwise valid. Whether the package is seen, relayed, admitted to mempools, and selected by miners is a matter of policy and implementation.

On the miner side, current Bitcoin Core block assembly asks the mempool for transaction “chunks” or packages. The assembler checks whether a package’s aggregate feerate is high enough and whether it fits remaining block limits such as weight and sigops. If so, the package is included. This package-aware construction is the practical reason a high-fee child can pull in its low-fee parent.

Why can relay policy block a CPFP attempt even if miners want it?

A common misunderstanding is that if miners benefit from CPFP, the network will always relay CPFP packages automatically. Historically, that has not always been true. There is a gap between “a miner would like this package if it saw it” and “ordinary nodes will accept and forward the necessary transactions under mempool rules.”

That gap becomes visible when the parent’s feerate is below a node’s current dynamic mempool minimum feerate. In congested conditions, nodes do not just apply a fixed floor like the minimum relay feerate. They may also require new transactions to beat the fee level of transactions that were recently evicted when the mempool was full. A weak parent can fail that test on its own, even if the child would make the pair attractive overall.

This is why package acceptance policy matters. Bitcoin Core’s package policy documentation defines a package as a topologically sorted connected directed acyclic graph of transactions, with parents appearing before children. For mempool submission, the topology currently accepted is much narrower: a child-with-parents package, meaning exactly one child plus at least one of its unconfirmed parents. For such packages, the node can evaluate package feerate, defined as total modified fees divided by total virtual size of the non-deduplicated transactions in the package.

The important consequence is that the combined package feerate may be used to meet the dynamic mempool minimum feerate. In other words, a parent that would be rejected by itself can sometimes be accepted together with a fee-paying child. That is CPFP at the mempool-admission layer, not just at the block-construction layer.

Bitcoin Core 28.0 introduced a limited practical version of this for 1P1C packages, meaning one parent and one child. In that setting, a single low-fee parent can enter the mempool if paired with a single child that pays enough for the package. Wallet guidance now recommends submitpackage for explicitly publishing such packages so upgraded nodes can evaluate the combined feerate instead of seeing an underpriced parent in isolation.

Why does Bitcoin limit which transaction packages it will relay and accept?

If package relay and package acceptance make CPFP more reliable, why not allow arbitrary webs of dependent transactions? The answer is not that Bitcoin developers missed the idea. It is that every additional topology makes validation, accounting, and denial-of-service resistance more difficult.

Package handling is expensive because the node must reason about transactions not merely one at a time, but in dependency order and with fee aggregation. Bitcoin Core therefore keeps strict bounds on package processing. The package policy documentation states that submitted packages cannot exceed MAX_PACKAGE_COUNT = 25 transactions or MAX_PACKAGE_WEIGHT = 404000 weight units. Packages submitted to the mempool must currently be child-with-parents only, not arbitrary transaction graphs. Even package replacement is heavily restricted today, limited to narrow cases such as one-parent-one-child package RBF with additional constraints.

These limits are not arbitrary neatness. They are there because package validation expands the attack surface. A node that naively accepted large or complex packages could be forced to do costly dependency analysis over and over. So CPFP support in policy has developed cautiously: enough to cover important real uses, not enough to permit every imaginable package shape.

That caution also explains a subtle warning in the package policy docs: batched multi-parent fee bumping may be unsafe. The documentation does not fully unpack every danger, but the broad point is that as package topologies get more complicated, reasoning about conflicts, relay reliability, and pinning resistance gets harder.

What is the CPFP carve-out and how does it protect Lightning?

There is a second layer of policy around CPFP that matters for advanced uses: the CPFP carve-out. To see why it exists, you need one more piece of mempool structure.

Bitcoin Core tracks ancestor and descendant counts and sizes for in-mempool transactions. Those limits prevent unbounded chains from consuming resources. But they can also create a pinning problem. In a two-party contract protocol, one party may need the ability to attach a fee-paying child to an unconfirmed transaction. If an attacker can fill up descendant slots and cause any additional child to be rejected, they may be able to block that fee bumping path.

The carve-out is a narrow exception designed to prevent that. Bitcoin Core developer documentation says that if a transaction would otherwise be rejected for exceeding descendant limits, an exemption can apply when three conditions hold: the candidate is no larger than 10,000 virtual bytes, it has an ancestor count of exactly 2 including itself, and adding it would cause the in-mempool transaction’s descendant count to exceed the limit by exactly 1. In effect, a small single-child fee-bump can sometimes get through even when descendant accounting would otherwise reject it.

The stated rationale is explicit: to prevent pinning in two-party contract protocols such as the Lightning Network. That makes CPFP carve-out less of a general convenience rule and more of a surgical policy hack to preserve an important safety valve under existing mempool limits.

It is worth being precise here. The carve-out is not CPFP itself. CPFP is the broader fee-bumping technique. The carve-out is a relay-policy exception that makes some CPFP transactions possible in cases where generic descendant-limit rules would have blocked them.

When will CPFP succeed and when will it fail?

CPFP is powerful because it solves a real coordination problem. If the original sender is offline, uncooperative, or unable to replace the transaction, a recipient can sometimes take matters into their own hands by spending the unconfirmed output. That is why CPFP is especially useful for wallets receiving funds and for contract protocols built around pre-signed transactions.

But CPFP has sharp boundaries.

First, it depends on access to a spendable output. If you are the sender and your original transaction has no change output you control, you may not be able to do CPFP yourself. If you are the recipient but the wallet does not support spending unconfirmed change or unconfirmed received outputs in that situation, the path may be awkward or unavailable.

Second, CPFP depends on miner and node policy, not just consensus. If miners ignored package feerates, CPFP would be weak. If relay policy could not get the package to miners, CPFP would also be weak. In practice, Bitcoin Core’s ancestor-aware mining and ongoing package-relay work make CPFP viable, but viability is still a matter of deployment and implementation.

Third, package propagation is still a work in progress. BIP 331 specifies Ancestor Package Relay, adding protocol messages for requesting and relaying unconfirmed ancestor packages and for batching transaction downloads. Its motivation is directly connected to CPFP: high-fee descendants should be able to bring their low-fee ancestors along, and nodes should be able to resolve orphan and package relationships more intelligently. But the protocol is receiver-initiated and depends on safe package-acceptance policy. It is a real step forward, not a magic guarantee that all CPFP attempts will propagate perfectly.

Fourth, the miner’s package-selection algorithm is a heuristic. Bitcoin Core developers were clear when ancestor-feerate mining was introduced that the approach improves fee income and is almost strictly better than the earlier algorithm, but it does not guarantee globally optimal blocks in every mempool configuration. There can be package interactions the heuristic does not exploit perfectly.

Finally, adversarial behavior still matters. Observational tools comparing block templates and mined blocks show that miners do not always include exactly what a default Bitcoin Core template would suggest. Sometimes that is due to timing, local mempool differences, or pool-specific prioritization. Sometimes it may reflect filtering or out-of-band incentives. The practical lesson is not that CPFP fails by default, but that Bitcoin has no single global mempool and no universal miner policy, so real-world inclusion remains probabilistic.

CPFP vs RBF: when to use fee-bumping and why they differ

Because both techniques are used to unstick transactions, readers often treat CPFP and Replace-By-Fee as interchangeable. They solve related problems, but with different levers.

RBF changes the original transaction by replacing it with a new version that pays more. That is usually the cleanest approach when the sender controls the transaction and marked it replaceable or otherwise can construct a valid replacement under policy. CPFP leaves the original transaction untouched and instead creates a descendant with enough fee to make the package attractive. That is useful when the sender cannot or will not replace, but someone else controls an output from the unconfirmed transaction.

They also interact. Modern policy work includes narrow forms of package RBF, especially for one-parent-one-child cases, so that a new child can help a new parent replace an old in-mempool parent package. This is a sign of the direction of travel: wallet and node policy are moving toward treating some dependent transactions more explicitly as fee-carrying packages rather than isolated objects.

Which CPFP behaviors are protocol rules and which are node/miner policy?

The fundamental part of CPFP is very small.

Bitcoin’s UTXO model creates explicit parent-child dependencies. Consensus requires parent-before-child ordering. A miner seeking fees can rationally consider the total fees of a parent-child package because the child cannot be included alone. Those facts are the bedrock.

Almost everything else people discuss under CPFP is policy and engineering convention. Ancestor-feerate mining is an implementation choice, albeit a very important one. Package relay is a protocol extension for better propagation, not a consensus change. Mempool package limits, carve-outs, 1P1C topology restrictions, and submitpackage are all policy tools designed to make the basic economic idea work safely on a hostile network.

That distinction helps clear up confusion. If a specific CPFP attempt fails, the reason is usually not “CPFP violates Bitcoin.” The reason is more often that some policy assumption was false: the package did not propagate, the child did not pay enough, the topology did not fit accepted package rules, descendant limits interfered, or miners had different local incentives.

Conclusion

**Child Pays for Parent means using a high-fee child transaction to make a low-fee parent worth mining as part of a package. ** It exists because Bitcoin transactions are linked by spend dependencies, and once those dependencies exist, the economically relevant unit is often the package, not the single transaction.

The memorable version is simple: a stuck parent can be rescued if someone can spend its output and pay enough for both.

Everything beyond that is Bitcoin’s ongoing effort to make that simple idea work reliably without opening the door to abuse.

• mempool package rules
• carve-outs
• package relay
• wallet support

How do you buy Bitcoin?

If you want practical exposure after reading about CPFP, buy Bitcoin on an exchange like Cube Exchange and manage on-chain fees when you withdraw. Fund your Cube account, place an order on the BTC market, then choose the withdrawal address and network (SegWit/Bech32 to reduce on-chain fees) when you move coins on-chain.

1. Deposit fiat (bank transfer or card) or a supported crypto (e.g., USDC) into your Cube account.
2. Open the BTC/USD or BTC/USDC market and choose an order type; use a market order for immediate execution or a limit order to control price.
3. Enter the BTC amount, review the estimated trade fees and on-chain withdrawal fee, and submit the order.
4. If you plan an on-chain withdrawal, select a SegWit/Bech32 address to lower on-chain transaction fees and confirm the network details before sending.