Your Bitcoin payment is stuck in the mempool.
The sender can’t—or doesn’t want to—replace it with a higher-fee transaction.
But the recipient still needs the payment to confirm.
Is there anything the recipient can do?
Sometimes, yes.
A technique called CPFP, short for Child Pays for Parent, can help.
Instead of replacing the original transaction, CPFP creates a new transaction that spends an output from the unconfirmed transaction. The new transaction pays a higher fee, making the combined parent-and-child package more attractive for inclusion in a block.
That’s why it’s called Child Pays for Parent.
The child transaction helps “pay” for the low-fee parent.
What Is CPFP?
CPFP is a Bitcoin fee-bumping technique that uses two related transactions:
Parent → Child
The parent is the original transaction that has not confirmed.
The child spends an output created by that parent.
The child pays a relatively high fee.
Miners can evaluate the transactions together and consider the fees earned from the package rather than looking at the parent’s fee in isolation.
Bitcoin’s developer glossary describes CPFP as a form of ancestor mining, where miners consider the fees of related ancestors and descendants when selecting transactions.
The concept can be represented simply:
Parent Transaction
Low Fee
↓
Unconfirmed Output
↓
Child Transaction
High Fee
↓
Combined Package
↓
Block
The child doesn’t magically change the fee of the parent.
Instead, the two transactions become economically connected because the child depends on the parent.
Why Would You Need CPFP?
Bitcoin block space is limited.
When demand increases, users compete by offering higher transaction fees.
Imagine a sender creates a transaction when the network is relatively quiet.
The transaction pays:
5 sat/vB
A few minutes later, the mempool becomes much more crowded.
Now transactions paying:
20 sat/vB
40 sat/vB
or:
60 sat/vB
may be competing for block space.
The original transaction may remain unconfirmed.
If the sender controls the transaction and their wallet supports fee bumping, RBF may provide a solution.
But what happens if the recipient is the person who needs the transaction to confirm?
That’s where CPFP can become useful.
Why Can the Recipient Use CPFP?
Suppose Alice sends Bitcoin to Bob.
The transaction looks like this:
Alice's Input
↓
Parent Transaction
↓
Bob's Output
The parent hasn’t confirmed yet.
Bob’s wallet can see the incoming output, but he cannot spend it on the blockchain until the parent is confirmed in the ordinary sense of final spendability.
However, an unconfirmed transaction output can still sometimes be used as an input to another unconfirmed transaction.
Bob can create a child transaction that spends the incoming output.
The child can pay a much higher fee.
Now the two transactions form a package:
Alice → Parent → Bob's Output → Child
The child depends on the parent.
A miner considering the package can look at the fees earned from both transactions.
A Simple CPFP Example
Imagine Alice sends Bob:
0.010 BTC
The parent transaction pays a very low fee:
0.00001 BTC
It remains unconfirmed.
Bob wants to use the incoming Bitcoin to make another payment.
He creates a child transaction that spends the unconfirmed output.
The child pays:
0.00050 BTC
in fees.
The package now looks like:
Parent:
0.00001 BTC fee
+
Child:
0.00050 BTC fee
=
0.00051 BTC combined fees
The child is expensive by itself.
But miners don’t need to confirm the child separately from its parent.
For the child to become valid on-chain, the parent must also confirm.
So the package can be economically attractive even though the parent alone has a poor fee rate.
Why Is It Called the “Child”?
The names come from transaction dependency.
The original transaction is the:
Parent
The transaction that spends one of the parent’s outputs is the:
Child
For example:
Parent TX
|
└── Output
|
↓
Child TX
The child cannot exist independently of the output it spends.
If the parent never confirms, the child cannot simply appear in the blockchain as though the parent had confirmed first.
Bitcoin’s package-processing logic therefore treats this relationship as a transaction dependency. Current Bitcoin Core has explicit package handling for one-child-with-parents structures.
CPFP Does Not Replace the Parent
This is the biggest difference between CPFP and RBF.
With RBF:
Original Transaction
↓
Replacement Transaction
The new transaction conflicts with the old one.
With CPFP:
Parent Transaction
↓
Child Transaction
The child depends on the parent.
The original transaction stays.
That’s why these techniques should not be confused.
RBF
Replace
CPFP
Add a dependent transaction
Who Can Use CPFP?
Usually, the person who controls an output from the unconfirmed transaction.
That could be:
The recipient
or:
The sender
or another party that controls a spendable output created by the parent.
The classic example is a recipient who receives Bitcoin in a low-fee transaction and wants to help push the entire transaction package toward confirmation.
A recipient therefore doesn’t always have to sit and wait for the sender to increase the fee.
A Merchant Example
Imagine you’re a merchant.
A customer sends:
0.05 BTC
to your Bitcoin wallet.
The transaction appears.
But the fee is too low.
The transaction remains unconfirmed.
You have already received an output from the transaction.
You now want to send part of that Bitcoin elsewhere.
Your wallet may be able to create a child transaction spending the unconfirmed output.
The child transaction pays a higher fee.
Conceptually:
Customer
↓
Parent: 0.05 BTC payment
↓
Merchant's unconfirmed output
↓
Child: merchant spends part of it
↓
High fee
The high-fee child can make the combined transaction package more attractive to miners.
That’s the central practical use of CPFP.
CPFP Does Not Create Bitcoin
Another common misunderstanding is that the child transaction somehow adds money to the original transaction.
It doesn’t.
The child is spending value from an output created by the parent.
The extra fee comes from the child transaction’s own inputs and outputs.
For example:
Parent creates:
0.010 BTC output
Child spends:
0.010 BTC
Child might create:
0.008 BTC → Next destination
0.002 BTC → Fee
The child is choosing to give up more of its own input value as a fee.
The parent itself has not been edited.
Where Does the Child’s Fee Come From?
Usually, the child pays the higher fee by giving less value to its own outputs.
Suppose the child spends:
0.010 BTC
and initially intends to send:
0.0098 BTC
to another address.
The fee would be:
0.0002 BTC
If the transaction needs a much higher fee, it might instead send:
0.0090 BTC
and use:
0.0010 BTC
as the fee.
The extra fee comes from the amount being spent in the child transaction.
Why Doesn’t the Child Need to Have a High Fee Rate by Itself?
This is where CPFP gets interesting.
Imagine the parent is huge and pays a tiny fee.
The child is small but pays a very large fee.
The child can compensate for the parent’s poor fee rate when the transactions are evaluated as a package.
For example:
Parent:
300 vB
3,000 sats fee
Child:
100 vB
17,000 sats fee
Together:
400 vB
20,000 sats
Combined package fee rate:
50 sat/vB
The child is effectively helping pull the parent upward in the economic ranking of the package.
The exact acceptance and mining behavior depends on node policy and package handling.
But this is the central economic idea behind CPFP.
Package Fee Rate
A useful concept when learning CPFP is the combined fee rate.
You can calculate it roughly as:
Total package fees ÷ Total package virtual size
Using the example above:
20,000 sats ÷ 400 vB = 50 sat/vB
The parent by itself paid:
3,000 ÷ 300 = 10 sat/vB
The child paid:
17,000 ÷ 100 = 170 sat/vB
But when considered together:
50 sat/vB
This combined figure explains how a high-fee child can compensate for a lower-fee parent.
The child isn’t changing the parent’s transaction.
It is changing the economics of the package.
Why This Matters to Miners
Miners earn transaction fees from confirmed transactions.
If a child transaction depends on a parent, the miner cannot normally confirm the child without also including the parent.
So the miner can consider:
Parent fee + Child fee
and:
Parent size + Child size
together.
That’s the basis of ancestor/descendant fee selection.
Bitcoin Core’s documentation describes this broader model as selecting transactions based not only on individual fees but also on the fees of related ancestors and descendants.
What If the Parent Pays Almost Nothing?
CPFP can become especially useful when the parent’s fee rate is low but the transaction is otherwise valid and still present in the relevant mempool.
Imagine:
Parent:
1000 vB
100 sats fee
Child:
100 vB
19,900 sats fee
Combined:
1100 vB
20,000 sats
Combined package fee rate:
18.18 sat/vB
The child is paying a huge fee relative to its size.
That expensive child can make the combined package much more attractive than the parent by itself.
However, current Bitcoin Core package policy has specific limits and conditions, so a sufficiently expensive child does not mean that every possible parent-child combination will automatically be accepted or relayed.
Can CPFP Work With Multiple Parents?
More advanced transactions can depend on multiple unconfirmed parent transactions.
Bitcoin Core’s package-processing system supports child-with-parent package structures, subject to policy and package limits.
For example:
Parent A ──┐
├──→ Child
Parent B ──┘
The child spends outputs created by more than one unconfirmed transaction.
This can become useful in more advanced wallet and application designs.
However, package policies become more complicated as the transaction graph grows.
For everyday Bitcoin users, the simplest model is still:
One low-fee parent + One high-fee child
CPFP and Your Wallet
You may never manually calculate any of this.
A wallet can expose a button such as:
“Speed up”
“Bump fee”
or:
“Accelerate transaction”
The wallet can then construct a child transaction when the transaction structure allows it.
The wallet determines:
- Which unconfirmed output to spend.
- How much value to send.
- How large the fee should be.
- Whether the transaction meets applicable policy.
- Which change output should receive any remainder.
Advanced wallets may expose these controls directly.
Other wallets may handle them automatically.
What Does CPFP Require?
At a high level, you need:
An unconfirmed parent transaction
and:
An output from that transaction that you can spend
The child then spends that output.
This is why CPFP is particularly useful to recipients.
A recipient can sometimes accelerate a payment without controlling the sender’s original transaction.
That is the major practical difference from RBF.
What If You Don’t Control an Output?
Then CPFP may not be available to you.
For example, if the unconfirmed transaction creates outputs that you do not control, you may not have anything you can spend as the child.
In that situation, you may need to:
- Wait.
- Ask the sender to use RBF.
- Use another fee-management method supported by the wallet.
- Wait for the transaction to confirm naturally.
CPFP requires a spendable dependency.
CPFP vs RBF at a Glance
The two techniques are easiest to remember side by side.
| RBF | CPFP | |
|---|---|---|
| Full name | Replace-by-Fee | Child Pays for Parent |
| Main idea | Replace unconfirmed transaction | Add a high-fee child |
| Original transaction | Replaced | Kept |
| Typical user | Sender | Recipient or output owner |
| Requires an unconfirmed output? | Not in the same sense | Yes |
| New transaction conflicts with parent? | Yes | No |
| Can recipient initiate it? | Usually not | Often yes |
| Main economic mechanism | Higher-fee replacement | Higher-fee package |
The simplest memory trick is:
RBF replaces.
CPFP adds.
CPFP Is a Fee-Bumping Tool, Not a Cancellation Tool
Just like RBF, CPFP does not let you cancel a transaction.
The parent is already out on the network.
The child simply creates another transaction that depends on the parent.
If the package gets confirmed, both transactions can become part of the blockchain.
So the result is:
Parent confirmed
plus:
Child confirmed
This is very different from RBF, where the replacement invalidates the usefulness of the original conflicting transaction for final confirmation.
How Is the CPFP Fee Calculated?
The most important concept is the combined fee rate.
Imagine the parent transaction is:
300 vB
with a:
3,000 satoshi fee
That gives it a fee rate of:
10 sat/vB
Now suppose the child is:
100 vB
with a:
17,000 satoshi fee
Its fee rate is:
170 sat/vB
Individually, the parent looks terrible.
But together:
300 vB + 100 vB = 400 vB
and:
3,000 + 17,000 = 20,000 sats
So the package fee rate is:
20,000 ÷ 400 = 50 sat/vB
The high-fee child effectively raises the economic value of the package.
Bitcoin Core’s transaction-selection model evaluates transactions together with their ancestors, which is the foundation for CPFP behavior.
Why Transaction Size Matters
Suppose two children both pay:
20,000 sats
but one is much larger.
Child A
100 vB
20,000 sats
200 sat/vB
Child B
1,000 vB
20,000 sats
20 sat/vB
Both pay the same absolute fee.
But Child A contributes much more fee per unit of block space.
That’s why a CPFP transaction can’t be evaluated only by asking:
“How many sats is the child paying?”
The wallet also needs to consider:
“How large is the parent-child package?”
That determines the combined fee rate.
The Parent’s Size Still Counts
This is easy to miss.
Suppose the parent is enormous.
Imagine:
Parent = 1,000 vB
with:
2,000 sats fee
The child is:
100 vB
with:
18,000 sats fee
Together:
1,100 vB
20,000 sats
Combined:
18.18 sat/vB
The child paid an extremely high fee for its own size.
But the parent is so large that it drags the package’s average down.
This is why a CPFP wallet doesn’t simply pick an arbitrary child fee.
It needs to calculate the entire package.
How Much Extra Fee Does the Child Need?
There isn’t one universal CPFP fee amount.
The correct fee depends on several things.
The wallet needs to consider:
- Parent size.
- Parent fee.
- Child size.
- Desired package fee rate.
- Current mempool conditions.
- Node policy.
- Package limits.
- Whether other unconfirmed transactions are connected.
Suppose:
Parent = 500 vB
Parent fee = 2,500 sats
You want the package to reach:
50 sat/vB
Then the total package fee would need to be approximately:
500 × 50 = 25,000 sats
If the child is:
100 vB
the total package size becomes:
600 vB
At 50 sat/vB, the package would need:
30,000 sats
The parent already contributes:
2,500 sats
So the child would need to contribute roughly:
27,500 sats
That is the simplified mathematical idea.
Actual wallet behavior is more complicated because it must account for the exact transaction structure and applicable relay/mining policy.
CPFP Uses the Child to Pull Up the Parent
Think of the parent as an anchor.
It doesn’t have a strong enough fee on its own.
The child attaches a much higher fee to that anchor.
Together:
LOW-FEE PARENT
500 vB
2,500 sats
|
↓
HIGH-FEE CHILD
100 vB
27,500 sats
|
↓
COMBINED PACKAGE
600 vB
30,000 sats
|
↓
50 sat/vB
The parent hasn’t changed.
Its original fee is still the original fee.
The child creates a better economic package.
That’s the core of CPFP.
What Is an Ancestor?
The word ancestor appears frequently in Bitcoin mempool discussions.
If transaction B spends an output from transaction A:
A → B
then:
A is the parent
and:
A is also B’s ancestor
Transaction B is A’s descendant.
If you have:
A → B → C
then:
- A is an ancestor of B.
- A is also an ancestor of C.
- B is a parent of C.
- C is a descendant of both A and B.
Bitcoin Core models unconfirmed transactions as a directed graph in which edges represent these parent-child relationships.
This matters because CPFP isn’t just about two unrelated transactions.
The child depends on the parent.
What Is a Descendant?
The opposite relationship is:
Child = descendant
Suppose:
Parent
↓
Child
The child is the parent’s descendant.
If another transaction spends an output from the child:
Parent
↓
Child
↓
Grandchild
the grandchild is also a descendant of the original parent.
These relationships matter because mempool policy can limit how many related transactions can be connected.
Why Mempool Limits Matter for CPFP
Bitcoin nodes can’t allow transaction graphs to grow without limits.
An attacker could otherwise create huge numbers of connected transactions and consume excessive CPU or memory.
Bitcoin Core therefore has limits involving ancestors, descendants, clusters, and package sizes.
Current Bitcoin Core defaults include a maximum of 64 transactions per cluster and a cluster virtual-size limit of 101 kB.
For ordinary CPFP transactions, these limits usually aren’t something users need to think about.
But advanced applications that create long transaction chains need to consider them.
What Happens When the Parent Is Below the Minimum Mempool Fee?
This is one of the most useful aspects of modern CPFP policy.
Suppose the parent transaction has such a low fee rate that a node would not normally accept it on its own because it falls below the node’s current mempool minimum.
A sufficiently high-fee child can sometimes allow the package to be accepted.
Bitcoin Core introduced package-CPFP support that allows a high-fee child to help a parent that is below the mempool’s minimum feerate, subject to package-policy rules.
This is important because it means CPFP is not merely a mining-selection trick.
It can also affect whether a parent-child package can enter a node’s mempool under the relevant package rules.
Minimum Relay Fee vs Mempool Minimum Fee
These terms are easy to confuse.
A node has policy thresholds governing what transactions it is willing to relay and keep.
When the mempool becomes crowded, the effective minimum fee rate for acceptance can rise.
A transaction can therefore be:
valid under Bitcoin consensus
while being:
rejected from a particular node’s mempool because its fee is too low for current policy.
Package CPFP can sometimes help a low-fee parent by evaluating the parent together with a high-fee child.
However, the exact policy rules matter.
A child cannot simply override every relay restriction.
Does the Child Always Propagate With the Parent?
Not necessarily in the simple way people imagine.
Package processing and package relay have evolved over multiple Bitcoin Core releases.
Bitcoin Core 26.0 added experimental package submission support, including package CPFP, but noted that successful package submission did not necessarily mean the package would propagate throughout the network because general package relay was not yet supported.
Bitcoin Core 28.0 later added limited one-parent/one-child package relay over the existing transaction relay mechanism.
Bitcoin Core 30.0 further improved opportunistic 1-parent-1-child package relay so these packages could work in more connected transaction topologies.
So modern CPFP is more capable than it was several releases ago, but users should not imagine that every node receives arbitrary multi-transaction packages in exactly the same way.
What Is Package Relay?
Normally, Bitcoin nodes relay transactions individually.
With package relay, related transactions can be communicated and evaluated together.
For CPFP, that’s useful because the economic value of the parent depends on the child.
Consider:
Parent
Low Fee
+
Child
High Fee
Evaluating only the parent may make it look unattractive.
Evaluating the package reveals the combined economics.
That is why package-aware relay is important for advanced CPFP workflows.
Why CPFP Can Be Hard Without Package Relay
Imagine the parent is below a node’s acceptance threshold.
If the node only sees:
Parent
it might reject it.
Then later it receives:
Child
But the child depends on an output from the parent.
If the parent isn’t known or accepted yet, the child cannot simply be treated like an independent transaction.
Package relay provides a way for the node to evaluate the related transactions as a unit.
That’s why package-based policy improvements have been an important part of recent Bitcoin Core development.
Can CPFP Fail Even With a Huge Child Fee?
Yes.
This is very important.
A massive child fee does not override every rule.
CPFP can fail because:
- The child spends an invalid output.
- The parent isn’t available.
- The transaction violates standardness or mempool policy.
- The package is too large.
- The transaction graph exceeds applicable limits.
- The child isn’t structured in an accepted package form.
- The output being spent is not actually controlled by the user.
- The wallet cannot construct a valid child.
So:
High fee ≠ guaranteed CPFP success
What If the Parent Has Multiple Unconfirmed Parents?
This creates a more complicated transaction graph.
For example:
Parent A ──┐
├──→ Child
Parent B ──┘
The child depends on two unconfirmed parents.
Modern Bitcoin Core package handling supports certain child-with-parents structures, but there are still restrictions on which package topologies can be accepted and relayed.
Current Core’s package validation code explicitly checks whether a package has the form of one child and its parents, and other checks apply to more complex trees.
So a simple:
Parent → Child
is much easier to reason about than a large transaction graph.
CPFP With a Change Output
CPFP can involve change outputs too.
Suppose your wallet creates:
Payment output
and:
Change output
The payment remains unconfirmed.
If you control the change output, your wallet could potentially spend that change output in a child transaction.
Then:
Parent
├── Payment
└── Change
↓
Child
The child uses the change output as its input.
This means you can sometimes increase the economic attractiveness of the parent without needing to alter the original transaction.
Why Change Is Valuable for Fee Management
This connects directly to the previous SatoshiDock article about change addresses.
A change output gives your wallet another UTXO that it controls.
That UTXO can later be spent.
For ordinary transactions, the wallet might simply keep it.
For CPFP, the wallet may use it as the input to a child transaction when appropriate.
So change isn’t only relevant to balances and privacy.
It can also provide flexibility for fee management.
CPFP and Hardware Wallets
CPFP can also work with self-custody.
Imagine a hardware wallet receives Bitcoin in an unconfirmed transaction.
The connected wallet software determines that CPFP may help.
It creates a child transaction.
The hardware wallet reviews the transaction and signs it.
The process is:
Unconfirmed Parent
↓
Wallet constructs Child
↓
Hardware Wallet reviews/signs
↓
High-fee Child broadcast
↓
Parent + Child package
↓
Confirmation
The private key stays inside the hardware wallet.
This is similar to RBF in the sense that the fee-bumping transaction can still be signed securely by an external signer.
CPFP From the Recipient’s Perspective
This is one of the most useful real-world situations.
Imagine you’re receiving Bitcoin.
The sender creates a low-fee transaction.
You cannot modify their transaction.
But one of its outputs belongs to you.
If the wallet supports CPFP, you may be able to create a child transaction spending your incoming output.
You effectively contribute your own funds to the fee through the child.
The combined package then has a higher effective fee rate.
That’s why CPFP is often described as a way for the recipient to help accelerate a payment.
But the Recipient Is Paying the Fee
This detail matters.
CPFP isn’t free.
If the recipient creates the child and gives up part of the child’s input value as a fee, the recipient is effectively paying for the acceleration.
Suppose you receive:
0.010 BTC
You create a child transaction spending that output.
If the child uses:
0.001 BTC
as the fee, only:
0.009 BTC
remains for the child’s outputs.
The sender didn’t pay that extra fee.
The recipient did.
This is one reason merchants sometimes use CPFP strategically when they need incoming transactions to confirm.
CPFP vs RBF: Who Pays?
This is a useful distinction.
RBF
The sender replaces the transaction and normally increases the fee using the transaction’s available value or additional inputs.
CPFP
The person controlling the parent output creates the child and pays the additional fee through the child’s inputs and outputs.
Therefore:
RBF → sender usually controls the fee bump
CPFP → recipient or output owner can sometimes control the fee bump
This distinction makes CPFP especially useful for incoming transactions.
A Practical CPFP Example
Imagine Alice sends Bob:
0.050 BTC
The parent transaction is:
500 vB
with a:
2,500 sat fee
That’s only:
5 sat/vB
The network becomes busy.
Bob needs the transaction confirmed.
Bob creates a child:
150 vB
with a:
17,500 sat fee
Now:
Total size = 650 vB
Total fees = 20,000 sats
Combined fee rate:
20,000 ÷ 650 ≈ 30.77 sat/vB
The parent is still only paying:
5 sat/vB
But the package is much more competitive.
The exact target fee depends on network conditions and the policies of the node/mining infrastructure involved.
What If the Child Is Too Expensive?
A wallet shouldn’t blindly maximize the child fee.
There is a trade-off.
Suppose paying an additional:
100,000 sats
might improve confirmation prospects only slightly.
That may not be sensible for a small payment.
The wallet should consider:
Payment value
Current fee market
Package size
Desired confirmation speed
Available UTXOs
Potential future spending costs
CPFP is a tool.
It isn’t automatically worth using every time a transaction is delayed.
Why a Child Can Sometimes “Rescue” a Parent
The word rescue is a useful metaphor, but it should not be taken literally.
The child isn’t repairing or modifying the parent.
The parent remains exactly what it was.
The child simply gives miners an economic reason to include both together.
Think of it like a package deal:
Parent:
"Include me and earn 1,000 sats."
Child:
"Include me too and earn another 19,000 sats."
Together:
"Earn 20,000 sats from this package."
That’s the economic logic behind CPFP.
The Most Important CPFP Rules to Remember
You don’t need to memorize Bitcoin Core’s entire package-policy implementation.
For practical understanding, remember these principles:
1. The child must spend an output from the parent.
2. The parent remains the parent.
3. The child pays the additional fee.
4. The package’s combined economics matter.
5. Transaction size matters.
6. Mempool and package policies still apply.
7. A high child fee does not guarantee confirmation.
8. CPFP requires an output you can actually spend.
These principles explain most ordinary CPFP situations.
CPFP in One Diagram
The complete concept can be summarized like this:
LOW-FEE PARENT
│
┌───────────┴───────────┐
│ │
Recipient Change
│ │
│ ↓
│ HIGH-FEE CHILD
│ │
└───────────┬───────────┘
↓
PACKAGE ECONOMICS
↓
BLOCK INCLUSION
The parent creates the output.
The child spends the output.
The child contributes the additional fee.
The package can become competitive for block inclusion.
How Wallets Use CPFP
Most Bitcoin users don’t calculate CPFP packages manually.
A wallet may detect that an incoming transaction is unconfirmed and provide an option such as:
Speed Up
Accelerate
or:
Bump Fee
Behind that button, the wallet can construct a child transaction that spends an output from the unconfirmed parent.
The wallet then calculates an appropriate child fee based on:
- The parent transaction’s size.
- The parent’s fee.
- The child’s size.
- Current fee conditions.
- The desired package fee rate.
- Applicable mempool policy.
The user may only see one simple button.
Underneath it, the wallet is solving a transaction construction problem.
CPFP With a Wallet-Controlled Change Output
CPFP isn’t limited to recipients.
The sender can sometimes use it too.
Imagine you broadcast a low-fee transaction containing:
Payment output
and:
Change output
The parent remains unconfirmed.
You may be able to spend your unconfirmed change output in a child transaction.
For example:
Parent Transaction
|
├── Recipient
|
└── Your Change
|
↓
Child Transaction
Higher Fee
The child spends your change.
Its fee can improve the combined economics of the parent and child.
This can be useful when the original transaction cannot simply be replaced through RBF.
CPFP and Hardware Wallets
CPFP can also work with hardware-wallet setups.
The connected wallet software can construct the child transaction while the hardware wallet protects the private key.
The process might look like:
Unconfirmed Parent
↓
Wallet Detects CPFP Opportunity
↓
Child Transaction Created
↓
Hardware Wallet Reviews
↓
Child Signed
↓
Child Broadcast
↓
Parent + Child Confirm
The private key remains inside the hardware wallet.
This is another example of why modern PSBT-based wallet infrastructure is useful for advanced Bitcoin transaction management.
CPFP and Merchants
CPFP can be especially useful for merchants.
Imagine a customer sends Bitcoin for a purchase.
The transaction arrives, but the fee is too low.
The merchant doesn’t control the customer’s original transaction.
However, the merchant may control the output created by that transaction.
The merchant can potentially create a child transaction that spends that incoming output.
The merchant then pays a higher fee to encourage the parent-child package toward confirmation.
This gives merchants a tool that doesn’t depend entirely on the sender’s wallet.
However, CPFP should not be treated as a guaranteed instant-confirmation mechanism.
It is still subject to node policy, fee competition, package structure, and mining conditions.
Who Pays for CPFP?
The person creating the child normally pays the additional fee.
That’s important.
Suppose Alice sends Bob:
0.01 BTC
Bob uses CPFP.
Bob creates a child spending that incoming output.
Bob may dedicate part of the value to the child’s fee.
So the extra fee is effectively paid by Bob.
This is one of the biggest differences between RBF and CPFP.
RBF
The sender replaces the original transaction.
CPFP
The owner of an output created by the parent creates the child and pays the additional fee.
Can CPFP Be Used With an Unconfirmed Change Address?
Yes.
This is one reason the previous SatoshiDock article about Bitcoin change addresses connects naturally with this topic.
A change output can become the input of a later child transaction.
That means a wallet-controlled change output can sometimes provide the value needed for a CPFP fee bump.
The relationship looks like:
Original Transaction
|
└── Change Output
|
↓
Child Transaction
|
Fee
The original transaction stays unchanged.
The child provides the additional fee pressure.
What Happens if the Parent Is Missing?
A child depends on the parent output it spends.
If a node doesn’t know about the parent, the child may be treated as having a missing input.
Modern Bitcoin nodes have mechanisms for handling transactions whose parents haven’t arrived yet, but package-aware submission and relay can improve the way parent-child transactions are processed together.
Bitcoin Core’s recent releases have expanded opportunistic one-parent-one-child package relay and improved handling of transactions connected to broader mempool topologies.
This matters because CPFP works best when the network can evaluate the parent and child together.
CPFP and Package Relay
Package relay is an important development for CPFP.
Traditionally, Bitcoin transaction relay treated transactions largely as individual objects.
But a CPFP relationship is inherently about a package.
The parent may be unattractive on its own.
The child may be highly attractive.
The economic value comes from looking at both together.
Bitcoin Core added package-CPFP support through package submission in version 26.0, and later releases expanded one-parent-one-child package relay over the peer-to-peer network.
This makes it easier for low-fee parents and high-fee children to be processed as related transactions.
Not Every Package Is Allowed
This is important for advanced users.
Bitcoin’s package system has defined structures and limits.
A simple:
Parent → Child
relationship is relatively easy to understand.
But larger graphs can become more complicated.
For example:
Parent A ──┐
├── Child
Parent B ──┘
or:
Grandparent
↓
Parent
↓
Child
Modern Bitcoin Core supports certain package structures but still checks package topology and policy constraints. Its package validation code explicitly distinguishes child-with-parents packages and child-with-parents trees.
So you cannot assume that adding more transactions will always produce a better CPFP package.
CPFP Does Not Override Consensus Rules
CPFP is a policy and transaction-selection technique.
It does not change Bitcoin’s consensus rules.
The child must still be a valid Bitcoin transaction.
Its inputs must be authorized.
Its scripts must be valid.
Its amounts must be valid.
Its outputs must obey Bitcoin’s rules.
The package also has to satisfy the relevant mempool and relay policies of the node processing it.
This distinction matters:
Consensus determines whether a transaction is valid.
Mempool policy determines whether a node is willing to accept and relay it.
What Happens if the Parent Is Extremely Low Fee?
A particularly interesting situation occurs when the parent has a fee rate below the current mempool minimum.
A high-fee child can sometimes improve the economics enough for the package to be accepted under package CPFP policy.
Bitcoin Core’s package-CPFP policy explicitly supports a child helping a parent below the mempool minimum feerate, subject to the applicable restrictions.
This is one of the reasons CPFP is useful when a transaction’s original fee was poorly chosen.
However, the parent cannot simply be invalid or violate arbitrary relay requirements.
A high child fee does not make an invalid parent valid.
What if CPFP Doesn’t Work?
Sometimes the wallet will refuse to create the child.
That can happen for several reasons.
No Spendable Output
You don’t control an output from the parent.
Wallet Doesn’t Support CPFP
The wallet may simply not provide the feature.
Insufficient Value
The available output may not provide enough value to make an economical child.
Policy Restrictions
The proposed package may violate current package or mempool policy.
Transaction Structure
The parent may already be part of a more complicated unconfirmed transaction graph.
Parent Status
The parent may no longer be present in the relevant mempool or may have been replaced.
In those situations, CPFP may not be the right solution.
CPFP vs RBF in the Real World
Imagine a Bitcoin transaction is stuck.
Which should you use?
Use RBF when:
You are the sender, the wallet can construct a replacement, and increasing the fee through replacement makes sense.
Use CPFP when:
You control an output from the unconfirmed transaction and want to use a child transaction to improve the package economics.
Use neither immediately when:
The fee is already competitive and the transaction has simply not reached the next block yet.
The right choice depends on the transaction structure.
CPFP vs RBF: The Simple Difference
Remember this:
RBF changes the transaction.
CPFP adds another transaction.
RBF:
Original
↓
Replacement
CPFP:
Parent
↓
Child
RBF is about replacing.
CPFP is about dependency.
Can CPFP Make a Transaction Confirm Immediately?
No.
CPFP can improve the economic attractiveness of a package.
It doesn’t control which miner includes the transactions or exactly when a block will be found.
Suppose your CPFP package reaches:
100 sat/vB
It may have excellent fee competition.
But a miner still needs to produce a block that includes it.
Network propagation also matters.
So:
Higher package fee rate = better economic position
not:
Higher package fee rate = guaranteed next-block confirmation
What Happens After the Parent Confirms?
Once the parent and child are included in a block, the relationship becomes ordinary blockchain history.
The parent creates its output.
The child spends it.
The child is no longer merely an unconfirmed dependent transaction.
The sequence becomes:
Block
|
├── Parent
|
└── Child
Both transactions are now part of the confirmed chain.
The fee market and mempool are no longer involved in deciding whether those transactions should be confirmed.
Can You Use CPFP More Than Once?
Technically, an output created by a transaction can be spent in a descendant transaction, creating longer chains.
For example:
Parent
↓
Child
↓
Grandchild
However, creating long chains purely to accelerate transactions can run into mempool and package limits.
For ordinary users, a single child is usually the easiest CPFP scenario to understand and manage.
Advanced Bitcoin applications may deliberately build more complicated transaction structures, but those require much more careful policy analysis.
Security Considerations
CPFP itself doesn’t expose your private keys.
The child transaction still needs valid authorization for the output being spent.
However, users should be careful when third-party websites or services ask them to “accelerate” transactions.
A legitimate fee-bump service should not need your:
Seed phrase
Private key
or:
Wallet password
You should sign the child transaction through your normal wallet or hardware wallet.
Never give a third party your recovery phrase simply because they claim they can accelerate a stuck transaction.
Common CPFP Mistakes
Paying an Excessive Fee
Don’t assume that an enormous child fee is automatically necessary.
Calculate the package economics and check your wallet’s recommended fee.
Spending the Wrong Output
The child must actually spend an output from the parent.
Assuming Every Wallet Supports CPFP
Wallet interfaces differ.
Confusing CPFP With RBF
RBF replaces.
CPFP adds a child.
Assuming Confirmation Is Guaranteed
The child improves the package’s economics but doesn’t control block production.
Giving Your Seed Phrase to an “Accelerator”
Legitimate fee-bumping software should not require your seed phrase or private key.
Ignoring the Child’s Own Size
A large child can consume enough block space to reduce the package’s effective fee rate.
Frequently Asked Questions
What does CPFP mean in Bitcoin?
CPFP stands for Child Pays for Parent. It is a technique where an unconfirmed child transaction pays a high fee to improve the economic attractiveness of the parent-child transaction package.
How does CPFP work?
The child spends an output from an unconfirmed parent transaction. Its high fee is considered together with the parent’s fee when evaluating the package.
Can the recipient use CPFP?
Yes, when the recipient controls an output from the unconfirmed parent and their wallet supports the required transaction construction.
Does CPFP replace the original transaction?
No. The original transaction remains the parent. The child depends on it.
Who pays the CPFP fee?
Normally, the person who creates the child pays the additional fee through the child’s inputs and outputs.
Can I use CPFP with Bitcoin change?
Yes. A wallet-controlled change output from an unconfirmed transaction can potentially be used as the input for a CPFP child.
Is CPFP the same as RBF?
No. RBF replaces an unconfirmed transaction. CPFP creates a child that spends an output from the parent.
Does CPFP guarantee the next block?
No. It improves the package’s economic attractiveness but doesn’t guarantee a particular confirmation time.
What is a parent transaction?
The parent is the earlier transaction whose output is spent by the child.
What is a child transaction?
The child is a transaction that spends an output created by the parent.
What is a package?
In this context, a package is a group of related transactions evaluated together, such as a parent and child.
What is the combined fee rate?
It is the total fees of the relevant package divided by its total transaction size, commonly expressed in sat/vB.
Can CPFP work when the parent has a very low fee?
Sometimes. Modern Bitcoin Core supports package CPFP that can allow a high-fee child to improve the economics of a parent below the mempool minimum feerate, subject to policy restrictions.
Can a CPFP child have multiple parents?
Some package structures allow a child with multiple unconfirmed parents, but package and relay policies impose restrictions. A simple one-parent/one-child structure is easier to support broadly.
Can a hardware wallet sign a CPFP transaction?
Yes. The wallet software can construct the child while the hardware wallet protects the private key and signs the transaction.
Can CPFP be used after the parent confirms?
It isn’t needed for the original confirmation problem. Once the parent is confirmed, the child is simply a normal transaction spending the parent’s confirmed output.
CPFP in One Example
Let’s reduce everything to one final scenario.
Alice sends Bob:
0.010 BTC
The parent transaction has:
500 vB
and:
2,500 sats fee
Fee rate:
5 sat/vB
The network is busy.
Bob’s wallet receives the unconfirmed output.
Bob creates a child transaction:
150 vB
with:
17,500 sats fee
Now:
Parent + Child = 650 vB
Total fees = 20,000 sats
Combined fee rate:
20,000 ÷ 650 ≈ 30.77 sat/vB
The parent hasn’t changed.
The child pays the additional fee.
Together, the transactions form an economically stronger package.
That’s CPFP.
Final Thoughts
CPFP is one of those Bitcoin features that seems strange until you understand the UTXO model.
A Bitcoin transaction can create an output that isn’t confirmed yet.
That output can become the input of another transaction.
The second transaction can pay a much higher fee.
When the two transactions are evaluated as a package, the child’s fee can help compensate for the parent’s low fee.
That’s the entire idea behind:
Child Pays for Parent.
The practical workflow is:
Low-fee parent
↓
Unconfirmed output
↓
High-fee child
↓
Combined package
↓
Package competes for block space
↓
Parent + child confirm
RBF and CPFP solve similar problems, but from opposite directions.
RBF replaces an unconfirmed transaction.
CPFP adds a high-fee child to an existing transaction.
That distinction matters.
A sender may be able to use RBF.
A recipient may be able to use CPFP.
And sometimes neither is necessary because the original transaction simply needs more time.
For everyday Bitcoin users, the most important lesson is not to panic when a transaction remains unconfirmed.
First determine what is actually happening.
Check the fee rate.
Check the mempool status.
See whether the transaction can be replaced.
See whether you control a spendable output.
Then choose the appropriate fee-management method.
CPFP isn’t a guarantee.
But when the conditions are right, it gives the owner of an unconfirmed output a powerful way to help move a stuck Bitcoin transaction toward confirmation.
