A wallet offers to add a fee through a child Bitcoin transaction, but looking only at the child’s own fee rate does not explain the total. The child depends on transactions that are still unconfirmed. Calculating a chosen set requires their sizes and already assigned fees as well. If two branches share an ancestor, that ancestor must not be added twice.
What CPFP means here
CPFP, Child Pays For Parent, uses a new transaction that depends on an earlier one. The Bitcoin Core FAQ describes the principle as adding fees through a dependent transaction. This differs from replacing the original transaction. Here we examine only the arithmetic of a predefined set; we do not construct or broadcast a transfer.
A real action requires a spendable output and the ability to sign a new transaction. Knowing somebody else’s payment TXID does not authorize spending its outputs. Sending BTC to an exchange deposit address does not give the sender control of that address. Only the relevant wallet can work with outputs it actually controls; this form verifies neither ownership nor available funds.
Draw the dependencies first
In the teaching example, transaction A has two different outputs. B uses one and C uses the other. A proposed child D uses suitable outputs from B and C. The chosen set therefore needs A, B, C and D, but A is still one transaction even though two paths lead to it.
| Label | Unconfirmed parents | Virtual size | Fee | How it is counted |
|---|---|---|---|---|
| A | None in this list | 200 vB | 1,000 sat | Shared ancestor, once |
| B | A | 200 vB | 1,000 sat | Direct parent of D |
| C | A | 200 vB | 1,000 sat | Another direct parent of D |
| D, proposed child | B and C | 200 vB | At least 5,000 sat for the entered target | Added to the union of ancestors |
| Total at a target of 10 sat/vB | A, B, C, D | 800 vB | 8,000 sat | Ancestors already contribute 3,000; D contributes another 5,000 |
A–D are labels, not transaction IDs. The 10 sat/vB target and all amounts are fictional: neither current network rates, KOT.CASH charges nor a recommendation to spend that fee. The supplied list is assumed to include every unconfirmed dependency of the selected parents. The tool cannot discover an unknown omitted transaction.
The formula for the entered target
Let V be the sum of unique ancestor virtual sizes, F their total fees, v the child’s virtual size and r the chosen fee rate. The full set needs at least ceil(r × (V + v)) satoshis. A fractional result is rounded upward because the absolute transaction fee is an integer number of satoshis. Subtract F to find the remaining contribution needed from the child.
If that remainder is negative, zero would suffice arithmetically. A user can also specify a separate absolute minimum for the child itself. The form takes the maximum of zero, that remainder and the entered minimum. It does not determine a network minimum. The displayed amount is a minimum for those two numerical conditions, not a guarantee of transaction acceptance.
For the example: ceil(10 × 800) − 3,000 = 5,000 sat. Counting A twice instead gives 1,000 vB and 4,000 sat of “ancestor” fees, leading to a 6,000 sat child. That extra thousand comes from duplicate counting, not a new network requirement.
Where the arithmetic stops
Do not automatically treat an entire connected graph as a package that a miner will certainly include. The Bitcoin Core 31.0 release notes discuss clusters and transaction groups called chunks. Node policy, relay and block construction involve more than a single aggregate rate. Our form neither reproduces those algorithms nor checks a live mempool.
It also does not verify that B and C spend different A outputs, whether other inputs conflict, whether signatures are valid, whether output values cover fees, which node limits apply or whether a wallet supports the proposed construction. A consistent dependency table is not a valid signed Bitcoin transaction.
Prepare the inputs for a useful check
- Use virtual size in vB, rather than raw bytes or weight without unit conversion.
- Enter each absolute fee in sat, not its sat/vB rate or the recipient’s payment amount.
- List only unconfirmed dependencies included in the model; do not expand the entire confirmed history behind them.
- Take a consistent snapshot. Rebuild the calculation after confirmation, replacement or a change in dependencies.
The list can include unrelated rows for reference. They appear as unused and do not increase totals. However, an unknown reference, duplicate identifier or cycle anywhere in the supplied graph is an error. The thirty-row limit keeps the local form small; it is not a Bitcoin policy rule.
Before exchanging, keep network fees separate from the service conditions of your order. The separate UTXO input-count article helps explain the size of one transaction. Here sizes are already supplied; the distinct task is combining dependent transactions and fees without duplicates. A downloaded result contains a teaching breakdown and does not sign or send funds.
Check a child fee against an entered aggregate-rate target
Local teaching arithmetic of a supplied dependency graph. Unique ancestors are counted once; integer sat and exact rounding up. All referenced IDs must exist; cycles are rejected. No UTXOs, signatures, balances, conflicts, node policy, relay, miner chunk selection, live fee estimates, wallet operations or confirmation guarantee. The entered minimum is not a discovered relay minimum; numerical limits are technical. The calculation runs on your device; nothing you enter is sent anywhere.