CPFP Carve-Out

What Is CPFP Carve-Out?

CPFP carve-out is a special relay policy rule in Bitcoin Core that grants an exception to the normal transaction descendant limits. Under default mempool policy, any unconfirmed transaction can have at most 25 descendants totaling 101,000 virtual bytes. The carve-out allows a 26th descendant if that child transaction has exactly one unconfirmed ancestor and is no larger than 10,000 virtual bytes.

The rule was proposed by Matt Corallo in November 2018 and merged into Bitcoin Core via PR #15681, shipping in Bitcoin Core 0.19.0 (November 2019). It is not a consensus rule or a BIP: it is purely a mempool relay policy change that nodes can adopt voluntarily.

The carve-out exists to solve a specific problem in the Lightning Network. When two parties share a commitment transaction, both need the ability to fee-bump it after broadcast using Child-Pays-for-Parent (CPFP). Without the carve-out, an adversary could prevent the other party from doing so by exhausting the descendant limit first.

How It Works

To understand the carve-out, you need to understand the normal descendant limits and why they exist.

Normal Descendant Limits

Bitcoin Core enforces package limits on unconfirmed transactions in the mempool to prevent denial-of-service attacks and limit the computational cost of transaction eviction:

These limits mean that once a transaction has 25 descendants in the mempool, nodes will reject any additional children spending from that transaction's outputs.

The Pinning Attack

Lightning commitment transactions are co-signed by both channel parties in advance. When broadcast, the pre-signed fee may be too low for current network conditions. Both parties need the ability to attach a CPFP child transaction to bump the fee.

The attack works as follows:

1. Alice and Bob share a Lightning channel with a commitment transaction that has two outputs: one for Alice, one for Bob
2. Bob broadcasts the commitment transaction with a low fee
3. Bob immediately attaches a chain of up to 24 low-feerate descendant transactions to his output, approaching the 25-descendant limit
4. Alice tries to attach a CPFP child to her output, but the node rejects it because the descendant limit has been reached
5. The commitment transaction is stuck at the original low feerate, and Alice cannot bump it

This is a form of transaction pinning. Because Lightning relies on timelocks, a pinned transaction that fails to confirm in time can result in lost funds.

The Carve-Out Exception

The carve-out adds a narrow exception to the descendant limit. A child transaction is accepted even when the descendant limit has been reached, as long as it meets these criteria:

1. It has exactly one unconfirmed ancestor (the parent transaction it is trying to fee-bump)
2. It is no larger than 10,000 virtual bytes
3. Only one such exception is permitted per transaction package

In Bitcoin Core's source code, this is defined as the constant EXTRA_DESCENDANT_TX_SIZE_LIMIT set to 10,000 vB in src/policy/policy.h.

// From Bitcoin Core src/policy/policy.h (prior to v31.0)
static constexpr unsigned int EXTRA_DESCENDANT_TX_SIZE_LIMIT = 10000;

// Default ancestor/descendant limits
static constexpr unsigned int DEFAULT_ANCESTOR_LIMIT = 25;
static constexpr unsigned int DEFAULT_DESCENDANT_LIMIT = 25;

In the attack scenario above, Alice can now attach her small CPFP child to her output as the 26th descendant because it meets the carve-out criteria: it has only one unconfirmed ancestor (the commitment transaction) and it is under 10,000 vB.

Use Cases

Lightning Anchor Outputs

The carve-out directly enabled the anchor outputs design in Lightning (specified in BOLT PR #688). Under this design:

• Each commitment transaction includes two anchor outputs (one per party), each worth 330 satoshis (the P2WSH dust limit)
• All other outputs (to_local, to_remote, HTLCs) are encumbered with a one-block CSV timelock, making them not immediately spendable
• Only the anchor outputs are immediately spendable, so each party can attach a CPFP child to their respective anchor
• The carve-out guarantees the second party can always fee-bump, even if the first party has saturated the descendant limit

This pattern solved a longstanding problem in Lightning: commitment transactions no longer needed accurate fee prediction at signing time. Either party could adjust the effective feerate at broadcast time through CPFP. For a deeper look at fee-bumping strategies, see Bitcoin Fee Bumping: RBF and CPFP Guide.

Two-Party Contract Protocols

While the carve-out was designed for Lightning, any two-party contract protocol with shared pre-signed transactions benefited from it. Protocols like discreet log contracts and atomic swap constructions face the same pinning risk when both parties need independent fee-bumping capability.

Risks and Considerations

Limitations of the Carve-Out

The carve-out was an effective but narrow solution with several limitations:

• It only works for two-party protocols: the rule allows exactly one extra child, so protocols with three or more participants cannot all benefit from the exception
• It requires maintaining a UTXO reserve for fee-bumping: each channel party needs a confirmed UTXO available to spend the anchor output, typically around 10,000 satoshis per channel
• The adversary can still make fee-bumping expensive: while they cannot block the CPFP child entirely, the existing descendant chain may force miners to evaluate a large package
• It is a relay policy, not a consensus rule: not all nodes are guaranteed to enforce the same carve-out rules, so relay is not fully deterministic

Removal in Bitcoin Core 31.0

The carve-out was removed in Bitcoin Core 31.0 (released April 2026) as part of the cluster mempool redesign. The cluster mempool architecture replaces ancestor and descendant limits with cluster-based limits (a maximum of 64 transactions and 101 kvB per cluster). Because the carve-out depends on per-transaction descendant tracking, it is fundamentally incompatible with the cluster-based model.

Replacement by TRUC Transactions and Ephemeral Anchors

The carve-out has been superseded by a more comprehensive set of solutions. For details on this transition, see Lightning v3 Transactions and Package Relay.

• TRUC (v3) transactions (BIP 431): transactions with nVersion=3 enforce strict topology limits of at most one unconfirmed parent and one unconfirmed child. Root TRUC transactions can be up to 10,000 vB, and child TRUC transactions up to 1,000 vB. TRUC transactions are always replaceable via RBF.
• Sibling eviction: if a new TRUC child would exceed the descendant limit, it can evict the existing sibling using RBF replacement rules. This eliminates the need for two separate anchor outputs entirely because either party can replace the other's child.
• Ephemeral anchors with Pay-to-Anchor (P2A): zero-fee parent transactions with a single anyone-can-spend output. The child pays the fee for the entire package via CPFP. This removes the 330-satoshi cost per anchor, eliminates the need for per-party anchor outputs, and enables zero-fee commitment transactions.

The progression for Lightning fee-bumping has been: fixed fees at signing time, then anchor outputs with the carve-out, and now TRUC transactions with ephemeral anchors. Each step has reduced the attack surface for transaction pinning while simplifying the protocol. Layer-2 protocols like Spark benefit from these improvements as they build on the same underlying Bitcoin transaction relay infrastructure.

CPFP Carve-Out vs. TRUC Transactions

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.