MASTERING-BITCOIN · Interactive Practice | Unit 10 · Video 3

When the Child Pays: CPFP and Package Relay

IKey Formulas

Formula	Name	Description
$\text{fee} = \text{fee rate} \times \text{vsize}$	Transaction fee	Total satoshis paid
$R_{\text{pkg}} = \dfrac{f_{\text{parent}} + f_{\text{child}}}{v_{\text{parent}} + v_{\text{child}}}$	Package fee rate	Combined sat/vB for parent + child
$R_{\text{anc}} = \dfrac{\sum f_i}{\sum v_i}$	Ancestor fee rate	Generalized to deeper chains

All fee rates are in satoshis per virtual byte (sat/vB).

IIVisualization 1: The Package Fee Rate Calculator

A parent transaction with a low fee can be "rescued" by a child that pays a high fee. Miners compute the combined fee rate of the package to decide whether to include it.

Use the sliders below to set the fee rates and sizes of the parent and child, then watch how the package fee rate changes. What fee rates must the child reach to lift a stingy parent above a busy-mempool minimum?

⚙ interactive visualization — coming to this page format soon

Notice: Try setting the parent rate to 1 sat/vB and the mempool minimum to 20 sat/vB. The parent alone is hopeless. How high does the child rate need to be (at default sizes) for the package to clear the floor? This is exactly the calculation miners do when ranking transactions for the next block.

IIIVisualization 2: The Mempool and the Orphan Child Problem

Modern Bitcoin nodes cap their mempool size and enforce a minimum fee rate. Transactions below the floor are rejected on arrival or evicted when space runs low. This creates a subtle failure mode for CPFP: if the parent is rejected, the child arrives as an orphan — its input references a transaction the node has never seen.

Toggle package relay on or off and adjust the parent's fee rate to see when the rescue succeeds vs. silently fails.

⚙ interactive visualization — coming to this page format soon

Reflect: Set the parent rate well below the floor (say 3 sat/vB, floor 15). With package relay off, even a generous child gets orphaned — the rescue silently fails. Now turn package relay on. The node evaluates the combined fee rate first, and the same child now succeeds. This is exactly why package relay is "load-bearing infrastructure" for protocols like the Lightning Network that broadcast presigned transactions whose fee rate may be obsolete by the time they hit the network.

IVPractice Problems

Question 1

A parent transaction has a fee rate of 2 sat/vB and a vsize of 250 vB. A child spending one of its outputs has a fee rate of 60 sat/vB and a vsize of 150 vB.

What is the package fee rate (sat/vB, rounded to the nearest whole number)?

✅ Correct! Package fee rate is total fees / total vsize ≈ 24 sat/vB.

❌ Not quite. Don't average the rates — sum the fees, sum the vsizes, then divide.

Show solution

Solution:

Compute total fees and total vsize, then divide.

Parent fee: $2 \times 250 = 500$ sats
Child fee: $60 \times 150 = 9{,}000$ sats
Total fees: $500 + 9{,}000 = 9{,}500$ sats
Total vsize: $250 + 150 = 400$ vB

$R_{\text{pkg}} = \frac{9{,}500}{400} = 23.75 \approx 24 \text{ sat/vB}$

The closest option is ~25 sat/vB.

The 31 sat/vB answer comes from incorrectly averaging the two fee rates: $(2 + 60)/2 = 31$ . That's wrong — you must weight by vsize.

Question 2

A customer pays you with a Bitcoin transaction whose fee is far too low. The customer is now offline, so you cannot ask them to do anything. Which technique can you, the receiver, use on your own to speed up confirmation?

✅ Correct! CPFP needs no cooperation from the sender — only access to one of the parent's outputs.

❌ Not quite. Remember: RBF requires the original signer, and you can't mine a single transaction on demand.

Show solution

Solution:

RBF requires the original sender's signature — you don't have it, and the sender is offline. So RBF is unavailable to the receiver.

CPFP works because you control the new output: spending the unconfirmed funds creates a child transaction signed entirely by you. Miners using ancestor fee rate mining will see that confirming the high-fee child requires confirming the low-fee parent first, so they drag the parent along.

The trade-off: both parent and child get mined (you pay for extra block space), but no cooperation from the sender is needed.

Question 3

True or False: Without package relay, a CPFP rescue can silently fail because the node receives the child first (or in isolation), cannot find the parent in its mempool, and rejects the child as an orphan — even though the child's fee would have made the combined package acceptable.

✅ Correct! This is the orphan child problem — CPFP fails in exactly the situation it was designed for.

❌ Not quite. Without package relay, nodes evaluate transactions one at a time and have no way to see that a high-fee child is waiting.

Show solution

Solution:

True. This is precisely the failure mode the video describes. Each node maintains a mempool with a minimum fee rate. If the parent's fee rate is below that floor, the node either rejects the parent on arrival or evicts it later. When the high-fee child then arrives:

The node inspects the child's input.
It references a transaction the node has never seen (or has already evicted).
The child is rejected as an orphan.

The node evaluates transactions one at a time, so it cannot know that a generous child exists to justify keeping the parent. Package relay fixes this by bundling parent and child together and evaluating their combined fee rate at the gate.

Question 4

Alice and Bob open a Lightning channel and presign a commitment transaction at 5 sat/vB. Months later, the mempool minimum is 20 sat/vB and Bob has gone offline maliciously. Alice must broadcast the old commitment to reclaim her funds.

Why is package relay critical for Alice's safety here?

✅ Correct! Presigned transactions can't use RBF, and CPFP needs package relay to survive a fee-rate environment that has drifted above the parent's rate.

❌ Not quite. Think carefully: RBF needs the other party's signature, and there's no way to bypass the mempool — transactions must propagate through nodes to reach miners.

Show solution

Solution:

Alice is stuck because:

RBF is impossible — replacing the commitment requires Bob's signature, and Bob is gone.
CPFP is her only tool — she attaches a high-fee child to her own output of the commitment.
But the parent is below the mempool floor (5 sat/vB < 20 sat/vB), so without package relay the parent never reaches anyone's mempool, and her child gets orphaned everywhere.

With package relay, both transactions travel together as a bundle. Each node computes the combined fee rate, sees it clears the floor, and accepts both. They reach miners, get confirmed together, and Alice recovers her funds.

This is why the video calls package relay "load-bearing infrastructure" for Lightning and any protocol that depends on presigned transactions whose fee rates may become stale.

The other options are wrong:

❌ RBF needs Bob's signature.
❌ There is no way to "bypass the mempool" — miners only mine what they've accepted.
❌ Package relay does not change the mempool minimum.

Solved: 0 / 4