# Child pays for parent: how a second transaction can lift the first

Child pays for parent, or CPFP, spends an output of an unconfirmed transaction in a new transaction whose fee can raise the combined package fee rate. A miner evaluating the dependent package can collect both fees, but the parent must precede the child, potentially within the same block. A usable output, wallet support and applicable relay policy are necessary.

Evidence: [Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html); [Bitcoin Core package policy](https://raw.githubusercontent.com/bitcoin/bitcoin/v29.0/doc/policy/packages.md)

Canonical: https://degreesofsatoshi.com/encyclopedia/child-pays-for-parent/
Published: 2026-10-02
Substantively modified: 2026-10-02
Independently verified by an automated reviewer: 2026-10-02T18:15:23.891Z
Data current through: 2026-10-02

AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied.

## Key facts

- **Dependency:** A child spends an output created by its parent. ([Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html))
- **Authority:** You need the keys or other authorization required to spend that output. ([Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html))
- **Combined rate:** For the simplified package example, combined fee rate is total fees divided by total virtual size; node policy can adjust fees and deduplicate existing transactions. ([Segregated Witness consensus layer](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki); [Bitcoin Core package policy](https://raw.githubusercontent.com/bitcoin/bitcoin/v29.0/doc/policy/packages.md))

## Why a child helps its parent

Imagine a low-fee payment with an output controlled by its recipient. The recipient can spend that output onward, creating a dependency. A miner cannot include this child as a valid spend without making the parent’s output available.

The sender may instead control a change output and use that. CPFP is therefore about output control, not exclusively about being the sender or recipient.

Evidence: [Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html)

## Calculate the combined rate

Suppose a parent is 200 vbytes and pays 200 satoshis. A child is 100 vbytes. To make the combined 300-vbyte package pay an illustrative 10 sat/vB, total fees must be 3,000 satoshis, so the child contributes 2,800. Setting the child alone to 10 sat/vB would be insufficient.

The arithmetic describes a target package rate, not a promise of relay or inclusion. Actual software has dependency, package and conflict limits, and a wallet may not support this operation.

Evidence: [Segregated Witness consensus layer](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki); [Bitcoin Core package policy](https://raw.githubusercontent.com/bitcoin/bitcoin/v29.0/doc/policy/packages.md)

## Check the output before constructing a child

The parent output must be spendable by your wallet. The child’s selected inputs must together fund its outputs and fee; a wallet may add other inputs if needed. Spending an output you do not control is not an option. A watch-only view of a payment cannot supply the necessary signature.

If the parent is replaced, a child referring to the old parent’s transaction ID may no longer be usable. Follow the actual dependency chain in an explorer and the wallet’s current transaction state.

Evidence: [Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html); [walletcreatefundedpsbt RPC](https://bitcoincore.org/en/doc/29.0.0/rpc/wallet/walletcreatefundedpsbt/)

## Questions

### Is CPFP the same as RBF?

No. CPFP creates a dependent spend; RBF creates a conflicting replacement. They rely on different outputs, permissions and policy conditions.

Evidence: [Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html); [Opt-in Full Replace-by-Fee](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0125.mediawiki)

## Claims and scope

### child-pays-for-parent-quick-answer

Child pays for parent, or CPFP, spends an output of an unconfirmed transaction in a new transaction whose fee can raise the combined package fee rate. A miner evaluating the dependent package can collect both fees, but the parent must precede the child, potentially within the same block. A usable output, wallet support and applicable relay policy are necessary.

Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null}

### child-pays-for-parent-fact-dependency

Dependency: A child spends an output created by its parent.

Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null}

### child-pays-for-parent-fact-authority

Authority: You need the keys or other authorization required to spend that output.

Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null}

### child-pays-for-parent-fact-combined-rate

Combined rate: For the simplified package example, combined fee rate is total fees divided by total virtual size; node policy can adjust fees and deduplicate existing transactions.

Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null}

## Sources

- [Bitcoin Developer Guide: Transactions](https://developer.bitcoin.org/devguide/transactions.html) — Bitcoin developer documentation contributors. UTXO inputs, transaction outputs, change and the difference paid as a fee. Locator: P2PKH Script Validation; Transaction Fees And Change. Retrieved: 2026-10-02T17:03:41.190Z.
- [Bitcoin Core package policy](https://raw.githubusercontent.com/bitcoin/bitcoin/v29.0/doc/policy/packages.md) — Bitcoin Core. Package fee accounting and policy for dependent transaction admission. Locator: Package Mempool Acceptance Rules; Package Fees and Feerate. Retrieved: 2026-10-02T17:21:46.897Z.
- [Segregated Witness consensus layer](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki) — Bitcoin BIPs contributors. Transaction weight and virtual-size definitions in the SegWit specification. Locator: Block size; Transaction size. Retrieved: 2026-10-02T17:22:20.465Z.
- [walletcreatefundedpsbt RPC](https://bitcoincore.org/en/doc/29.0.0/rpc/wallet/walletcreatefundedpsbt/) — Bitcoin Core. Input selection, fee units, change output, selected inputs and transaction funding. Locator: Arguments and result fields. Retrieved: 2026-10-02T17:03:40.827Z.
- [Opt-in Full Replace-by-Fee](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0125.mediawiki) — Bitcoin BIPs contributors. Historical opt-in replacement signaling and replacement policy conditions. Locator: Summary; Implementation Details. Retrieved: 2026-10-02T17:22:20.573Z.

## Revision history

- 2026-10-02: Initial Bitcoin encyclopedia entry at this permanent URL.
- 2026-10-02: Added reusable claims, explicit source locators, and matching Markdown and JSON. This publishing change does not itself establish factual verification.

## Cite this entry

Degrees of Satoshi editorial project. “Child pays for parent: how a second transaction can lift the first.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/child-pays-for-parent/