Package CPFP

What Is Package CPFP?

Package CPFP is a mempool policy that evaluates a group of related transactions (a "package") together when determining whether they meet the minimum relay fee threshold. Instead of requiring each transaction to independently satisfy the node's feerate floor, package CPFP allows a low-fee or zero-fee parent transaction to enter the mempool as long as its child transaction pays enough fees to cover both.

Traditional child-pays-for-parent (CPFP) only works when the parent is already in the mempool. If the parent's feerate falls below the node's dynamic minimum (which rises during congestion), the parent is rejected outright. The child never gets a chance to boost it because it references an unknown parent. Package CPFP solves this chicken-and-egg problem by letting nodes consider both transactions as a unit.

How It Works

Package CPFP relies on package relay: the ability for nodes to submit, validate, and accept groups of related transactions together rather than one at a time. Here is how the process works under Bitcoin Core 28.0's one-parent-one-child (1P1C) implementation:

1. A node receives a child transaction that references an unconfirmed parent the node has not seen
2. The node tracks the child as an orphan and requests the missing parent from the peer that sent the child
3. When the parent arrives, the node evaluates both transactions together as a package
4. The combined feerate of the package (total fees divided by total virtual bytes) is compared against the mempool's minimum feerate thresholds
5. If the package feerate meets the requirements, both transactions are accepted into the mempool simultaneously

Package Feerate Calculation

The package feerate is straightforward: sum the fees of all transactions in the package, then divide by the total weight of the package in virtual bytes. This means a small, high-fee child can compensate for a large, zero-fee parent:

Package feerate = (parent_fee + child_fee) / (parent_vsize + child_vsize)

Example:
  Parent: 200 vB, 0 sats fee
  Child:  150 vB, 3,500 sats fee
  Package feerate = 3,500 / 350 = 10 sat/vB

Even though the parent pays zero fees, the package as a whole achieves 10 sat/vB, which may be sufficient for mempool acceptance depending on current conditions.

1P1C Topology Constraints

Bitcoin Core 28.0's implementation restricts packages to a strict one-parent-one-child topology. Several constraints apply:

• The package must contain exactly one parent and one child transaction
• The child must not have any other unconfirmed parents: if it does, the package will not propagate through the P2P network
• Non-TRUC transactions must still meet the static minimum relay fee of 1 sat/vB individually
• Only TRUC (v3) transactions are allowed to have truly zero-fee parents

Full ancestor package relay, as described in BIP 331, remains a draft proposal. It would allow more complex package topologies with multiple ancestors, but the current 1P1C mechanism covers the most pressing use case: fee bumping pre-signed transactions with a single child.

Why Package CPFP Matters for Lightning

The Lightning Network depends heavily on package CPFP for secure channel force-closes. When two parties open a Lightning channel, they pre-sign commitment transactions that can be broadcast to settle the channel on-chain. The problem: these transactions are signed days, weeks, or months before they might be broadcast, making it impossible to predict the feerate needed for timely confirmation.

The Anchor Output Solution

Lightning's answer is anchor outputs: small outputs attached to the commitment transaction that exist solely for CPFP fee bumping. When a party needs to force-close, they broadcast the commitment transaction and immediately create a child transaction that spends the anchor output, paying whatever feerate is needed at that moment.

Without package CPFP, this approach fails during high-fee periods. If the commitment transaction's feerate is below the current mempool minimum, nodes reject it before the fee-bumping child can help. The commitment transaction never enters the mempool, and the channel party cannot enforce the on-chain settlement they need.

With package CPFP, the commitment transaction and its fee-bumping child are evaluated together. Even a zero-fee commitment can propagate as long as the child pays enough for both. For a deeper look at how these mechanisms interact, see the research article on Lightning v3 transactions and package relay.

Ephemeral Anchors and Pay-to-Anchor

The full picture includes several companion policies that work alongside package CPFP:

• TRUC transactions (BIP 431): opt-in via nVersion 3, these restrict package topology to one parent and one child (child limited to 1,000 vB) and allow zero-fee parents
• Pay-to-Anchor (BIP 433): a new output type using a keyless script that anyone can spend, replacing the channel-party-specific anchor outputs used previously
• Ephemeral anchors: combine TRUC topology rules with P2A outputs and ephemeral dust relay policy, allowing zero-value anchor outputs in zero-fee transactions

Together, these features enable a cleaner Lightning force-close flow: the commitment transaction carries zero fees and a single shared P2A output. Either channel party (or a watchtower) can attach a CPFP child at broadcast time, paying the exact feerate needed at that moment.

Use Cases

Lightning Channel Force-Closes

The primary use case for package CPFP. Pre-signed commitment transactions cannot predict future feerates, so they rely on package evaluation to reach the mempool during congestion. The Lightning specification (BOLTs #1228) defines a zero-fee commitment format using a single shared P2A output, designed specifically to leverage package CPFP.

Pre-Signed Transaction Protocols

Any protocol that uses pre-signed transactions faces the same fee prediction problem. This includes discreet log contracts (DLCs), CoinPools, timeout trees, and vault constructions using OP_VAULT. Package CPFP allows these protocols to pre-sign transactions with minimal or zero fees and defer fee decisions to broadcast time.

Wallet Fee Bumping

Regular wallet users benefit when a sent transaction drops below the mempool minimum during a fee spike. With package CPFP, the wallet can create a child spending the change output to boost the stuck parent without waiting for the parent to be independently relayed. For a practical walkthrough of both RBF and CPFP fee bumping techniques, see the complete guide to fee bumping stuck Bitcoin transactions.

Comparison: Traditional CPFP vs. Package CPFP

Risks and Considerations

Network Adoption Lag

Package CPFP requires the receiving node to support 1P1C relay. Nodes running Bitcoin Core versions before 28.0 will reject below-minimum-fee parents even when a valid child exists. Until the majority of the network upgrades, package propagation may be unreliable. Wallet developers can use the submitpackage RPC to submit packages directly to their own node, bypassing P2P relay limitations.

Limited Package Topology

The current 1P1C implementation only handles the simplest case: one parent and one child. More complex scenarios (multiple unconfirmed ancestors, chains of unconfirmed transactions) are not yet supported in relay. A child with multiple unconfirmed parents will not propagate through the P2P network under 1P1C rules.

Blockspace Overhead

Package CPFP inherently requires two transactions: the parent and the fee-bumping child. This consumes more blockspace than a single transaction using replace-by-fee (RBF) to adjust its own feerate. For protocols that can use RBF directly, it remains more blockspace-efficient. However, pre-signed transactions (like Lightning commitments) cannot use RBF because modifying the transaction would invalidate existing signatures.

Transaction Pinning

Transaction pinning attacks attempt to prevent fee bumping by attaching a large, low-fee descendant to the parent. TRUC transactions mitigate this by limiting the child to 1,000 vB and allowing immediate replacement of any existing child with a higher-feerate alternative. The older CPFP carve-out rule addressed a narrower version of this problem but has been superseded by the TRUC and package CPFP approach.

Fee Estimation Complexity

Wallets and Lightning nodes must correctly estimate the child transaction's fee to achieve the desired package feerate. This requires accounting for the parent's size and fee (potentially zero), the child's size, and the current fee market conditions. The fee estimation algorithm must target the combined package feerate rather than the child's individual feerate.

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.