Bitcoin CPFP (Child Pays for Parent)

What Is Bitcoin CPFP (Child Pays for Parent)?

A Bitcoin transaction that creates an output is the parent. A later transaction spending that output before the parent confirms is the child. Because the child depends on the parent, a miner generally cannot include the child in a block without including its parent first. CPFP takes advantage of that dependency by attaching a higher fee to the child.

Bitcoin Core’s mining and mempool policies can evaluate related unconfirmed transactions together. If their combined fees are attractive relative to their combined virtual size, a parent and child can be selected together even when the parent’s individual fee rate is too low. These are policy mechanisms rather than changes to Bitcoin’s consensus rules, and other miners or nodes may use different policies or hold different local mempool views.

When Can CPFP Help an Unconfirmed Bitcoin Transaction?

CPFP requires a spendable output from the unconfirmed parent and the ability to satisfy that output’s script conditions. Depending on the transaction structure, that output could be a payment output or a change output. Timelocks, multisignature requirements, or other script conditions can prevent immediate spending.

It is most relevant where the parent has a low fee rate and waiting is undesirable. Before creating a child, check whether the wallet has an RBF option, whether the transaction is actually visible to the intended recipient or service, and whether the available output is large enough to fund the child’s fee. If the situation is unclear, the Stuck Bitcoin Transaction Guide at /learn/stuck-bitcoin-transaction can help distinguish a low-fee transaction from other causes of delay.

Who Can Create the Child Transaction?

Any party that can validly spend a suitable unconfirmed parent output can construct the CPFP child. In a typical payment, that may be the recipient spending the payment output or the sender spending a change output. Whether a wallet exposes or automatically selects an unconfirmed output depends on that wallet’s policy and interface.

Control of the relevant spending path is what matters: the creator must be able to satisfy the output’s script conditions, and the wallet or signing software must allow that outpoint to be used. Wallet interfaces and coin-selection policies vary, and custodial services may expose or restrict this workflow through their own policies.

How Parent and Child Transaction Fees Are Evaluated Together

For a simple two-transaction CPFP calculation, compare the parent and child together: (parent fee + child fee) divided by (parent virtual size + child virtual size). Virtual size is commonly expressed in vbytes. In Bitcoin Core mempool and RPC data, `vsize` is sigops-adjusted virtual size; fee rates are commonly expressed in sat/vB. A higher child fee can raise the package’s average fee rate.

For example, assume a parent is 200 vbytes and pays 2 sat/vB, giving it a 400-satoshi fee. If its 150-vbyte child pays 4,850 satoshis, the package pays 5,250 satoshis across 350 vbytes, or 15 sat/vB. A miner considering that package has an incentive that the parent alone did not provide.

A favorable package calculation is not a confirmation promise. Miners choose transactions according to their own policies and available block space, while nodes may reject, retain, or evict transactions based on local policy. Additional unconfirmed ancestors or descendants can also complicate package handling.

How to Calculate the Child Fee for CPFP

Start by choosing a target package fee rate based on your own urgency and a current fee estimate. Then estimate or obtain the virtual sizes and fees of both transactions. For this two-transaction calculation: required child fee = target package rate × (parent vbytes + child vbytes) − parent fee. Round upward to avoid falling below the intended rate.

Suppose the parent is 220 vbytes with a 1,100-satoshi fee, and the child is expected to be 140 vbytes. To target 18 sat/vB for the 360-vbyte package, the combined fee needs to be 6,480 satoshis. The child therefore needs at least 5,380 satoshis. The child must also have an output value sufficient to pay that fee while still creating a valid transaction, including any output that the wallet requires.

Use actual transaction data rather than guessing fees from the bitcoin amount sent. The Bitcoin Fee Estimator at /bitcoin-fee-estimator can provide a reference point for selecting a target, but a wallet’s size estimate and fee controls determine the final child transaction. Avoid setting a fee from an outdated screen or assuming a displayed estimate is a guarantee of next-block inclusion.

CPFP vs RBF: Which Fee-Bumping Method Fits?

Under a node’s applicable replacement policy, Replace-by-Fee (RBF) replaces an unconfirmed transaction with another transaction that spends one or more of the same inputs and pays the required additional fee. Whether a replacement is accepted depends on the node’s current policy and the replacement transaction. A wallet may expose this to the sender as a fee-bump option.

CPFP creates a separate child rather than replacing the parent. It can fit when the recipient controls the useful output, when the sender wants to spend their unconfirmed change, or when RBF is unavailable or unsuitable. A parent that cannot be replaced through RBF can still potentially be accelerated with CPFP if an appropriate output is spendable.

The methods can have different operational consequences. RBF may change a transaction ID and can affect systems waiting for the original transaction, while CPFP leaves the parent transaction intact and adds another transaction to track. For more detail on replacement behavior, see the Bitcoin Replace-by-Fee (RBF) Guide at /learn/bitcoin-replace-by-fee-rbf.

Why CPFP Can Fail or Remain Unconfirmed

CPFP cannot work if there is no output from the parent that the relevant party can spend. It also fails when the selected output is too small to support the child fee, when a wallet will not spend unconfirmed coins, or when signing requirements and timelocks prevent a valid child from being made. Spending an output that is already spent by another transaction is not possible.

A child may be valid but still not achieve the desired package fee rate because its size or fee was estimated incorrectly. Multi-input transactions can be substantially larger than expected, and additional unconfirmed ancestors may mean that the miner evaluates a broader package than the simple parent-child example. Node policies can impose limits on unconfirmed transaction chains and package handling.

Finally, propagation matters. If a transaction is absent from a miner’s local mempool, or was evicted there during congestion, that miner cannot select it. Seeing a transaction in one explorer does not prove universal visibility; separate nodes can disagree temporarily about which unconfirmed transactions they have accepted.

How to Check the Parent and Child Transactions

First, look up the parent transaction ID in the Bitcoin Transaction Checker at /bitcoin-transaction-checker. Confirm that it is unconfirmed, inspect its outputs, and identify which output is intended for the child. Check that this output has not already been spent and that its value, script conditions, and ownership match the wallet or recipient expected to construct the child.

Next, open the child transaction after it has been broadcast. Its inputs should reference the parent transaction ID and the specific output index being spent. Compare the parent fee and virtual size with the child fee and virtual size, then calculate the combined package fee rate. Also verify that the child was not accidentally constructed with a low fee or a large number of extra inputs.

Once either transaction confirms, inspect the block record and confirmations rather than relying on a pending status cached by a wallet. If the parent confirms, the child can confirm later on its own merits; if both appear in the same block, that is direct evidence that the package was included together.

Monitor CPFP Transactions with UnlockPool

UnlockPool’s transaction checker is useful for following the parent-child relationship: search each transaction ID, review the child input that spends the parent output, and check confirmation status as blocks arrive. The Bitcoin Mempool Tracker at /bitcoin-mempool can provide context on congestion and current fee pressure, while recognizing that it reflects the mempool data available to that service rather than a single worldwide mempool.

For a practical workflow, record the parent transaction ID, identify the spendable output, create the child only through a wallet or signing setup you trust, and then check both IDs separately. Use the fee estimator before choosing the child fee, and revisit the transaction records after broadcast to confirm that the intended input, fee, and change outputs are correct.

Frequently Asked Questions

Summary

CPFP can improve an unconfirmed transaction’s effective fee rate without changing the parent. Confirm a spendable parent output exists, calculate the package fee from actual vbytes and fees, and verify both transaction IDs after broadcast. Results still depend on wallet capabilities, node policy, miner selection, and mempool conditions.