Child-Pays-For-Parent (CPFP)

The most common use case. When a low-fee transaction is stuck in the mempool, a user can create a new transaction that spends one of its outputs (the UTXO). This new, higher-fee child transaction creates a transaction package. Miners are incentivized to include both to collect the total fee, unblocking the original parent transaction.

• Example: A wallet broadcast a payment with 5 sat/vB; network congestion pushes the required fee to 15 sat/vB. The sender creates a CPFP transaction spending that payment's change output with a 20 sat/vB fee.

Critical for services requiring guaranteed confirmation within a specific time window, such as:

• Arbitrage trades across exchanges
• Liquidations in DeFi protocols
• Time-locked contracts or payment channels

Using CPFP provides a deterministic method to increase priority without relying on Replace-By-Fee (RBF), which must be signaled by the original transaction. This makes it essential for operational reliability in high-stakes financial operations.

A vital tool for wallets and services that use transaction batching. If a batched transaction containing dozens of payments gets stuck, all constituent payments are delayed. A recipient of one of those payments can use CPFP to accelerate the entire batch by spending the output they received.

This shifts the fee-bumping responsibility and cost from the original sender to the recipient who needs urgency, solving a common coordination problem in UTXO-based blockchains like Bitcoin.

Essential in complex smart contract or multi-signature setups on Bitcoin-like chains (e.g., Lightning Network channel closures, DLC settlements).

• If a cooperative closing transaction is broadcast with insufficient fee, any participant can CPFP it.
• In a 2-of-3 multisig vault, any key holder can bump the fee for a withdrawal, ensuring the transaction eventually confirms without requiring all signers to coordinate a replacement.

This provides robustness and reduces failure points in decentralized protocols.

Used strategically when sudden spikes in network demand create a fee market auction. Users who initially underbid can use CPFP to outbid newer, higher-fee transactions. It is also a defense against mempool gaps, where miners may selectively clear high-fee transactions, leaving lower-fee ones stranded. By attaching a high-fee child, the package becomes more attractive than individual transactions, ensuring it is not skipped.

CPFP and RBF are the two primary fee-bumping methods. Key differences:

• CPFP: Requires a spendable output from the stuck transaction. Can be performed by anyone who can spend an output (sender OR recipient). Creates a dependent child tx.
• RBF: Requires the original transaction to signal RBF (nSequence < 0xffffffff-1). Can only be performed by the original sender. Replaces the original tx entirely.

Use CPFP when you are the recipient, the tx didn't signal RBF, or you want to avoid invalidating downstream dependencies.

CPFP works by creating a dependent transaction that spends an output from a stuck parent transaction. Miners are incentivized to include both transactions in a block to collect the combined fees. This creates a package where the child's higher fee effectively subsidizes the parent's low fee, making the entire package profitable to mine.

• Parent Transaction: A broadcasted but unconfirmed transaction with insufficient fees.
• Child Transaction: A new transaction that spends an output from the parent, carrying a high fee.
• Package RBF: The miner's mempool logic evaluates the fee rate of the entire transaction package.

Major wallets and exchanges implement CPFP to improve user experience with stuck transactions.

• User-Initiated: Wallets like Electrum allow users to create a CPFP transaction manually by spending a change output.
• Automated Bumping: Services may automatically construct and broadcast a child transaction when a user's withdrawal is delayed.
• Exchange Protocols: Custodial platforms use CPFP internally to clear backlogged withdrawal transactions from their hot wallets, ensuring timely processing for users.

CPFP's behavior and optimization are defined and enhanced through Bitcoin Improvement Proposals.

• BIP 125 (Opt-In RBF): While primarily for Replace-By-Fee, its signaling mechanism is often used in conjunction with CPFP strategies.
• Package Relay (Package Mempool Accept): Proposed upgrades to the P2P protocol to allow nodes to evaluate transaction packages directly, making CPFP more reliable and reducing pinning attacks. This is part of ongoing work to improve mempool policy.

CPFP directly interacts with network mempool and fee estimation algorithms.

• Fee Market Impact: A surge in CPFP usage can temporarily inflate mempool fee rates as users compete to bump transactions.
• Estimation Services: Advanced fee estimators account for the potential of CPFP, sometimes suggesting a "bump fee" option instead of a simple fee increase on the original transaction.
• Mempool Eviction: Low-fee parent transactions vulnerable to eviction due to memory limits can be rescued via CPFP before they are dropped from network nodes.

CPFP is a critical tool for managing Bitcoin's Layer-2 protocols, especially the Lightning Network.

• Channel Force-Closure: If a counterparty broadcasts an old state, a user can use CPFP to accelerate the confirmation of their justice transaction, penalizing the malicious party.
• Anchor Outputs: Modern Lightning channels use anchor outputs, which are small, low-fee outputs designed specifically to be spent via CPFP to bump the fee of the commitment transaction, enabling reliable channel closings.

While powerful, CPFP has specific constraints and risks.

• Spendable Output Requirement: Requires an unspent output from the parent transaction (e.g., change) that the user controls.
• Transaction Pinning: Attackers can use large descendant size or other techniques to make a child transaction expensive to mine, preventing CPFP. Proposals like ephemeral anchors aim to mitigate this.
• Not Universal: Some miners or mining pools may not honor package relay policies, though it is widely supported.

Replace-By-Fee (RBF) is a complementary fee-bumping mechanism where the original sender of a stuck transaction broadcasts a new version with a higher fee, signaling to miners to replace the original. Unlike CPFP, which creates a dependent child transaction, RBF modifies the original transaction directly. It is a protocol-level feature that must be explicitly opted into by the wallet creating the initial transaction.

The Mempool is a node's temporary holding area for unconfirmed transactions broadcast to the network. It is the arena where CPFP operates. When a transaction is stuck with a low fee, it resides in the mempool. The CPFP child transaction, with its higher fee, increases the combined fee rate of the parent-child package, making it more attractive for miners to select from the mempool and include in the next block.

Fee estimation is the process by which wallets predict the appropriate transaction fee (usually in satoshis per virtual byte) to ensure timely confirmation. Accurate estimation helps avoid the need for CPFP. Wallets use algorithms that analyze current mempool congestion and recent block space demand to suggest fees for high, medium, or low priority, directly influencing how long a transaction might remain unconfirmed.

An unconfirmed transaction chain is a sequence of dependent transactions where the output of one is spent by the next before the first is confirmed on-chain. CPFP explicitly creates such a chain. This dependency creates a package for miners. Miners evaluate the fee density of the entire package; if the child's fee is high enough, it makes mining the entire chain profitable, incentivizing them to include the parent.

Block space is the limited data capacity within a blockchain block, measured in weight or bytes. Miners are incentivized to fill this space with transactions that offer the highest fee rate (fee per byte). CPFP works by increasing the effective fee rate of a low-fee transaction package, making it competitive for inclusion. This highlights the auction-like nature of transaction confirmation in proof-of-work blockchains.

A transaction is built from inputs (unspent transaction outputs - UTXOs being spent) and outputs (new UTXOs created). For CPFP to work, the sender of the child transaction must control an output (change address) from the original, stuck parent transaction. This creates the necessary spend dependency. Understanding UTXO ownership is crucial for executing a CPFP operation successfully.