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

Pinned Down: Transaction Pinning & Lightning Defenses

IKey Rules Reference

Rule	Statement	Why It Matters
RBF Replacement Fee	$\text{new fee} > \text{original fee} + \sum \text{descendant fees}$	Attacker descendants inflate the replacement cost
Descendant Limit	$\leq 25$ descendants, $\leq 100{,}000$ vbytes per package	Once hit, CPFP is locked out by policy
CPFP Carve Out	$+1$ extra child, $\leq 1{,}000$ vbytes, parent has no unconfirmed ancestors	One surgical escape hatch per package
Package Work	$N$ descendants $\Rightarrow N^2$ related updates	Reason for the 25-descendant cap

IIInteractive Visualizations

Visualization 1: The RBF Pinning Attack

Alice broadcasts a small honest payment. Bob (the attacker) attaches a giant low-fee-rate child to one of its outputs. Because RBF requires the replacement to beat the entire subtree of fees, Bob's child makes it absurdly expensive for Alice to bump her own transaction.

Use the sliders below to control the attacker's child size and fee rate. Watch how the minimum RBF fee Alice must pay explodes.

⚙ interactive visualization — coming to this page format soon

Reflect: Notice that Bob's child can sit at the same low fee rate as Alice's transaction, yet still make her replacement absurdly expensive. Why? Because RBF measures total absolute fees of the replaced subtree, not the fee rate. A 100,000-vbyte junk child at 1 sat/vB pays 100,000 sats — a thousand times Alice's original 100-sat fee. The attacker doesn't need a high fee rate; they just need a big child.

Visualization 2: Why the Descendant Limit Exists

Bitcoin Core caps related transaction packages at 25 descendants and 100,000 vbytes. Adding a transaction forces nodes to recompute fee rates for the entire affected subtree. If we allowed $N$ descendants per parent and $N$ levels deep, the work grows like $N^2$ .

Use the slider to vary the descendant cap and watch how the package-evaluation cost scales.

⚙ interactive visualization — coming to this page format soon

Notice: Doubling the descendant limit from 25 to 50 doesn't double the work — it quadruples it, from 625 to 2,500 evaluations. This quadratic blow-up is exactly why the limit exists. The DoS protection is real and necessary. The unfortunate side effect: once that cap is reached, nobody can attach a CPFP child, including the honest party who needs to bump the fee.

Visualization 3: Carve Out — The Escape Hatch

Mallory attaches 25 junk children to her output of a co-signed parent transaction, hitting the descendant limit. Under normal rules, Bob can't add a child to his output — package is full. But the CPFP carve out allows one extra child if it's $\leq 1{,}000$ vbytes and the parent has no unconfirmed ancestors.

Toggle Bob's carve-out attempt and adjust his child's size to see when the escape works.

⚙ interactive visualization — coming to this page format soon

Reflect: Try setting Bob's carve-out child size above 1,000 vbytes. The carve out rejects it — the size cap is strict. This is deliberate: a generous carve out would just become a new pinning vector. The exception is surgical: one small high-fee child, attached to a fresh parent, is enough to drag the parent into a block. Lightning's anchor outputs are tiny dedicated outputs designed precisely so each party can use this narrow door independently.

IIIQuiz Questions

Question 1

Alice broadcasts a 100-vbyte transaction at 1 sat/vbyte (paying 100 sats in fees). Bob attaches a 50,000-vbyte child at 2 sat/vbyte to one of Alice's outputs.

To replace her transaction using RBF, what is the minimum fee Alice must pay (approximately)?

✅ Correct! Alice must beat the entire subtree's fees, not just her own.

❌ Not quite. Remember RBF measures the sum of all descendant fees, not just the parent.

Show solution

Solution:

RBF requires the replacement transaction to pay more in total absolute fees than the original transaction plus all its descendants combined.

Alice's original fee: $100 \text{ vB} \times 1 \text{ sat/vB} = 100$ sats
Bob's child fee: $50{,}000 \text{ vB} \times 2 \text{ sat/vB} = 100{,}000$ sats
Subtree total: $100 + 100{,}000 = 100{,}100$ sats

Alice's replacement must pay more than 100,100 sats — over 1,000× her original fee. This is the pinning trap: Bob's child doesn't even need a high fee rate, just a lot of weight.

Question 2

True or False: Bitcoin Core's descendant limits (25 descendants, 100,000 vbytes) exist primarily to stop pinning attacks.

✅ Correct! The limits exist for DoS resistance ( $N^2$ update cost). Pinning is an unintended side effect, not the problem they were designed to solve.

❌ Not quite. The descendant limits predate pinning concerns — they were introduced to bound node computation, and pinning exploits them rather than being prevented by them.

Show solution

Solution: False.

The descendant limits exist for denial-of-service protection — specifically, to bound the computational cost of mempool updates. Every time a transaction is added or removed, the node must recompute package fee rates for the affected subtree. With $N$ descendants, this work scales like $N^2$ , so a cap of 25 keeps the per-update cost at $\sim 625$ evaluations.

The cruel twist is that these DoS-protection limits also enable pinning: once the cap is reached, the policy refuses additional children, locking honest users out of CPFP exactly when they need it. The limits are a tradeoff, not an anti-pinning measure — pinning is a side effect of an otherwise reasonable rule.

Question 3

Which of the following is NOT a requirement for the CPFP carve-out exception to apply?

✅ Correct! Carve out is defined by structural conditions (size, ancestor count, single use) — not by a fee-rate comparison against other children.

❌ Not quite. That option is a real requirement of the carve-out rule. Look for the one that isn't part of the spec.

Show solution

Solution:

The CPFP carve-out rule has three conditions:

One additional child is allowed past the descendant and size limits.
That child must be at most 1,000 vbytes.
The parent must have no unconfirmed ancestors (it must be a freshly broadcast transaction with no unconfirmed history above it).

There is no requirement that the carve-out child pay a higher fee rate than the existing children — in fact, the whole point is that the existing junk children are typically low fee rate, and the honest user's carve-out child carries a high fee rate to drag the parent to confirmation via package evaluation. The rule is structural, not economic.

Question 4

Modern Lightning commitment transactions include two tiny "anchor outputs" with negligible value. What is their primary purpose?

✅ Correct! Anchors are dedicated carve-out slots — one per party — so neither party can be pinned out of fee-bumping their own commitment.

❌ Not quite. Anchors are tiny outputs with no economic purpose. Think about what each party needs in order to use the carve-out rule reliably.

Show solution

Solution:

Anchor outputs exist purely as dedicated CPFP attachment points — one per channel partner. They have no economic purpose.

The reasoning chains together everything in this lesson:

Lightning needs a way to fee-bump a pre-signed commitment transaction at broadcast time.
RBF doesn't work for pre-signed transactions (you'd need both parties to re-sign).
CPFP works, but a pinning attacker can attach 25 junk children and exhaust the descendant limit.
The CPFP carve-out rule allows one extra small child — but it's single use per package.
With two parties, one carve-out slot isn't enough if both could need it; the solution is two dedicated outputs, so each party has their own slot they alone can spend.

Each anchor is a guaranteed, exclusive channel for that party's carve-out child. A narrow policy exception (carve out) plus a structural commitment design (anchors) together neutralize the pinning attack for two-party channels.

Solved: 0 / 4