Bitcoin CPFP fees: Calculate parent and child before accelerating

Child-pays-for-parent creates a new transaction spending an unconfirmed parent's output with a fee intended to encourage their combined inclusion. It adds another transaction rather than rewriting the parent's fee. Check output control, both sizes and the extra cost you bear before signing.

Child-pays-for-parent creates a new transaction spending an unconfirmed parent’s output with a fee intended to encourage their combined inclusion. It adds another transaction rather than rewriting the parent’s fee. Check output control, both sizes and the extra cost you bear before signing.

A hypothetical weighted package
200 vB + 100 vBCombined size
200 sat + 2,800 satCombined fee
10 sat/vB3,000 divided by 300

The simple average of the individual rates, 1 and 28, is not the package rate.

BTKWIN.COM · EDUCATIONAL EXAMPLE

What parent and child mean

The parent creates an output; the child spends it. The child cannot appear in the chain before the output exists. They can be included in the same block with the parent ordered first. These names describe transaction dependency, not people or account ownership.

Bitcoin Optech’s CPFP explanation describes how a higher-fee child can make inclusion of an unconfirmed ancestor more attractive. The parent retains its identifier and fee while the child has another record and fee.

A recipient controlling a suitable unconfirmed receiving output might have a supported path, while a sender might use controlled change. Merely knowing an address or finding an explorer record does not grant authority to spend the relevant output.

Check the stage and who controls the output

First establish that a Bitcoin transaction was broadcast and remains unconfirmed. A platform withdrawal under internal review without a network identifier is another stage. An included payment awaiting service credit is another problem again.

If the output belongs to a custodial deposit address, that service generally manages its spending. Your personal wallet cannot impose a child on an output it does not control. Consult official service policy rather than assuming receiving a deposit entitles you to sign its network outputs.

Use our transfer help tool to organize the record. Elapsed minutes alone do not establish that CPFP is available, useful or within your authority.

Calculate the combined rate correctly

TransactionHypothetical sizeFee satoshisIndividual rate
Parent200 vB2001 sat/vB
Child100 vB2,80028 sat/vB
Combined300 vB3,00010 sat/vB

Weight by size instead of averaging rates

The combined rate is total fees divided by total virtual size: 3,000 divided by 300 equals 10 sat/vB. Averaging 1 and 28 gives 14.5, which ignores that the parent is twice as large as the child.

For this simplified two-transaction example, the child fee needed for a target rate is target multiplied by combined size minus parent fee. At 10 sat/vB, that is 10 times 300 minus 200, or 2,800 satoshis.

This is a budget equation, not a guarantee of network acceptance or a particular block. Sizes, target and current fees are assumptions. The actual wallet’s construction and applicable policy remain part of the decision.

Update the model when the transaction changes

If the wallet adds an input or changes outputs, the child size can change. At 150 vB for the child, total size becomes 350. Keeping the same hypothetical target then requires 10 times 350 minus 200, or 3,300 satoshis.

If the parent depends on older unconfirmed transactions, two records may not describe the whole relevant group. Their sizes and fees can matter too. Do not copy a number from a two-transaction table into a longer dependency chain.

Relay, acceptance and selection are not just arithmetic. Follow a supported wallet process and read any rejection reason. A correct weighted rate does not eliminate constraints elsewhere in the actual workflow.

Package incentive and your added cost are different

Suppose the output you control is 50,000 satoshis and a simple child returns one output to you while paying 2,800. The new output is 47,200 under those assumptions. You did not pay the package’s full 3,000 out of that output.

The parent’s 200-satoshi fee was part of the earlier transaction and might have been borne by another party. Separate the combined incentive calculation from the marginal cost of your own action.

If the child instead pays another person and deducts the fee from that payment, verify their net amount. A value selected on the first screen need not remain the recipient’s quantity after a fee-setting change.

Small outputs require a proportional decision

The additional fee can consume a large fraction of an output or leave an unsuitable result under wallet policy. Compare remaining value with the purpose and supported alternatives rather than seeking a high rate at any cost.

The transfer cost calculator can organize values you supply. Actual transaction size comes from the wallet’s relevant construction, not a fixed percentage of the balance.

You may decide to wait, ask the controlling service or use another supported mechanism. None is automatically best for every transaction. Document the reason and budget rather than reacting to an acceleration label.

Compare CPFP with RBF by authority and complete cost

RBF creates a conflicting replacement using overlapping original inputs. CPFP spends an output from the parent. This difference affects who can act and where the extra fee comes from. A recipient’s ability to spend their output is not equivalent to replacing the sender’s inputs.

Our RBF guide shows the other accounting model. Do not subtract parent and child fees as though one replaces the other, and do not assume either option is always cheaper or available.

A new independent payment with a similar recipient is neither mechanism by name alone. It can confirm alongside the original. The child must actually depend on an output created by the parent.

Track dependencies and outcomes

Replacing a parent can change its identifier and invalidate a child referencing an earlier output. Avoid coordinating unexplained fee attempts from several devices without preserving their relationships. Review the wallet’s current conflict and dependency information before acting again.

Retain parent and child IDs, proposed fees, sizes and submission time. Verify the actual destination on the trusted signing display. After broadcast, follow confirmation of both relevant transactions rather than treating a local accepted notice as final settlement.

A high rate is not a promise of inclusion in the next block. If the parent already confirmed, spending an output is no longer a way to recall the recipient’s funds. Keep acceleration, ordinary spending and requesting a refund as separate goals.

No public tracking service needs a recovery phrase to explain these records. Keep signing inside a verified workflow and seek official guidance with non-secret evidence if the construction remains unclear.

Continue reading

English content and examples reviewed: 27 October 2026. Read the Arabic edition.

تامر طعمه
تامر طعمه
Articles: 484