Imagine someone sent you bitcoin with a low fee and the payment is still unconfirmed. If your wallet supports CPFP for it, you can create a follow-up transaction, perhaps to another address of your own. The original is called the parent and the new one the child: the child spends an output, an amount with spending conditions, created by the parent. To collect the child’s fee, a miner needs the parent too. The original payment stays unchanged; the higher fee offer can help confirmation, but cannot guarantee when it happens.
Anna is waiting for 100,000 sat. The abbreviation sat means satoshi, the smallest unit of bitcoin. She can see the payment, but the sender chose a low fee and it is not in a block yet. Her wallet allows her to spend this unconfirmed output. Anna uses it to create a new transaction to her own address, offering a higher fee. She is not paying the sender or rewarding a separate service: she is paying an ordinary Bitcoin transaction fee. A miner cannot confirm this new transaction without the original, because the output it spends would be missing from the chain being validated. The parent must have confirmed earlier or appear before the child in the same block, along with any other necessary unconfirmed ancestors. The reverse is not true: the parent can confirm without the child. [3] [5]
Take a simple example with no other unconfirmed ancestors. The parent is 200 vB and pays 200 sat. A virtual byte, vB, measures size derived from transaction weight; sat/vB tells you how many satoshis are offered per such unit. The child is 100 vB and Anna pays 2,800 sat for it. With just one child output, her incoming 100,000 sat leaves her 97,200 sat. Together the transactions pay 3,000 sat for 300 vB: 10 sat/vB. The child alone offers 28 sat/vB, but the miner needs to include the low-fee parent transaction as well. Looking only at the child’s high number misses this dependency. This is an illustrative calculation, not today’s recommended rate; the wallet checks the actual sizes and required total fee. Additional necessary ancestors change the calculation. An advanced detail: local package acceptance does not recount transactions already accepted and the node — a program that checks and relays transactions — may use modified fees. The rate shown there need not match the simple combined calculation for a miner. A modified fee is a local value used by the node when making decisions; it does not change the fee actually paid by the transaction. [3]
CPFP is not a button that lets anyone speed up someone else’s transaction. You need authority to spend a parent output and must meet its conditions, including signatures. Anna can do this as the recipient; the sender may be able to use an output returning leftover funds, called change. Merely seeing an amount in an explorer or a Watch-only Wallet is not enough. A Watch-only Wallet tracks payments but does not itself hold the private keys needed to spend the funds. The wallet must also support spending the unconfirmed output. Before signing, check which output you are spending, where the funds will go, how much will remain and the total fee you will pay. For a small output, the fee can consume a substantial part of its value. [5]
Replace-by-Fee (RBF) creates a new conflicting transaction intended to replace the original. It shares at least one spent input, but does not need exactly the same complete input set. CPFP instead keeps the original payment and its identifier, adding another transaction. RBF requires meeting the replacement’s input conditions; ordinary CPFP requires meeting the original payment output’s conditions. This is why a recipient may be able to use CPFP even without being able to sign the sender’s replacement. Sending an unrelated payment with a large fee will not help: the child must actually depend on the pending payment. [3]
A higher combined rate gives a miner a better reason to take both transactions, but reserves no space in the next block. Better-paying transactions may arrive, or some miners may not receive the package. Track confirmations of both the original payment and the child. A node reporting acceptance is not yet a block confirmation. If the sender replaces the original payment through RBF, a child referring to its old output cannot attach itself to the different new transaction; the situation needs reassessing. Creating a child does not turn unconfirmed incoming funds into a guaranteed payment. [3]
The following sections cover rules for deeper reading and running your own node. A Mempool is one node’s list of pending transactions, not a shared network-wide queue. A package is a group of transactions submitted together. Three decisions must be distinguished: whether a transaction is valid, whether a node accepts it and whether a miner selects it. Consensus determines transaction and block validity. Mempool policy governs local acceptance and relay; miner rules govern selection for a candidate block. CPFP does not change consensus. An economically attractive package may fail local policy, and its acceptance by one node does not bind other nodes or miners. [3] [5]
Ways to relay a parent and child together keep evolving. Package CPFP means assessing related transactions as a package. An RPC is a command for interacting with a node; minrelaytxfee names its minimum rate for ordinary relay. TRUC is a special transaction regime with restricted ancestor and descendant relationships. The history below concerns the stated Bitcoin Core versions. Bitcoin Core 26 introduced the submitpackage RPC and package CPFP: a child could help a parent below the dynamic mempool minimum feerate, but at that time not below the minimum relay feerate. This restriction is not timeless. Core 31 allows a parent below minrelaytxfee, including zero fee, in supported one-parent-one-child package relay, also for non-TRUC transactions; any additional unconfirmed parents of the child must already be in the mempool. Local acceptance still does not guarantee identical propagation throughout the network. [1] [2]
A node cannot accept arbitrarily large networks of dependencies. An ancestor is needed before another transaction, while a descendant spends outputs further along the chain. WU means transaction weight units and topology describes how transactions are connected. These technical limits belong to the particular node version’s policy. Limits protect memory, processor resources and bandwidth. Older Core versions limited ancestor and descendant counts and sizes; Core 31 replaced those mempool limits with limits on connected clusters. Separate package limits remain: Core 31 documentation specifies at most 25 transactions and total weight of 404000 WU. Weight is not virtual size. Incorrect topology, a conflict or failure to meet local rules on accepted transaction forms (standardness) can block CPFP even with enough fee. [2] [3]
Pending transactions with dependencies cannot always be assessed economically in isolation. Cluster Mempool lets a node consider connected groups. A cluster is the whole connected group; a smaller group processed during transaction selection is a chunk. These are not pieces of already confirmed blocks. Bitcoin Core 31 uses Cluster Mempool: a cluster contains transactions connected through parent–child relationships in either direction. Default limits are 64 transactions and 101 kB of virtual size per cluster; they are configurable. Ordering considers groups mined together, called chunks, and their feerates. The historical CPFP carveout allowed a limited exception to the descendant limit; Core 31 removed it, and the cluster transaction count limit cannot be bypassed this way. [2] [4]
The commands in this section are not interchangeable. A test may only describe a result; submitting a package can actually accept and relay signed transactions. The vsize field gives virtual size. An ordinary wallet may handle these details for its user. In Core 31, getmempoolentry reports, for a transaction in that node’s mempool, fees, vsize, dependencies and chunk data; getmempoolcluster shows the related cluster. The testmempoolaccept RPC performs a local test without acceptance or broadcast; with multiple transactions, ancestors must precede children and the transactions must not conflict with each other or the mempool. The submitpackage RPC actually submits a supported package for mempool acceptance and relay; it is not merely a test. Inspect individual transaction results, version and configuration; no result guarantees inclusion in a block. [2] [6] [7] [8] [9]
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 Address, Confirmation, Double-spend, Fee Rate.