CPFP does not replace or edit the parent transaction. It creates a descendant whose fee can subsidize the ancestor package because the child cannot be mined without the parent. Effectiveness depends on combined package feerate, control of a parent output, mempool/package policy and miner selection.
Child Pays for Parent (CPFP) leaves a low-fee unconfirmed parent unchanged and spends one of its outputs in a higher-fee child. Because the child cannot be mined without the parent, miners can collect both fees by including the dependency package, so the child's fee can economically subsidize the parent.
For a simple parent-child package, the relevant rate is approximately (parent fee + child fee) divided by (parent vsize + child vsize). A large child fee is useful only if the combined package feerate becomes competitive for block space; looking at the child in isolation can be misleading.
Ordinary CPFP requires control of a spendable output created by the parent. The sender may use change; the receiver may use the payment output. A party that controls neither output cannot sign a valid child and therefore cannot perform normal CPFP on that transaction.
RBF and CPFP solve similar fee-bumping problems through different graphs. RBF creates a conflicting replacement spending the original inputs; CPFP preserves the parent and adds a descendant. RBF needs authority over the original inputs, while CPFP needs authority over a parent output.
Consensus determines whether the transactions are valid, mempool policy determines whether a node stores and relays them, and miner policy determines whether they enter a block template. CPFP changes none of Bitcoin's consensus rules; an economically attractive package can still fail local policy checks.
Bitcoin Core 26 introduced submitpackage and package CPFP evaluation. A high-fee child can help a parent that is below the node's mempool minimum feerate, but the parent still cannot be below minimum relay feerate. Local package acceptance also does not guarantee every peer will relay the same package.
Nodes limit transaction ancestry and dependency topology to bound memory, CPU and relay cost. A CPFP attempt can fail because of ancestor, descendant, standardness or package constraints even when the combined fee is high enough economically.
Bitcoin Core 31 moved mempool ordering toward cluster-based feerate diagrams and chunk feerates. The historical CPFP carveout was removed, so package behavior should be understood through current cluster and package policy rather than assuming the old special descendant-limit exception still exists.
A competitive package feerate improves the probability that miners will include the package, but it does not reserve space in the next block. Block-space demand, propagation and miner policy can change, so CPFP is a fee-bumping tool rather than deterministic finality.
Inspect parent and child with getmempoolentry, including fees, virtual sizes and dependency data. testmempoolaccept can test candidates and submitpackage can evaluate supported packages. The operational question is whether the complete dependency package is policy-valid and fee-competitive.
For the clearest picture, read this entry together with Replace-by-Fee (RBF), Transaction fees, Fee Rate, Mempool, Transaction, UTXO. The reverse links also lead from Change output, Confirmation, Double-spend, Fee Rate.