Welcome back, and thank you for being here to learn with me.This is Part 2 of my ongoing series where I dive deeper into Lightning Network anchor outputs and share what I'm figuring out as I go
Welcome Back
In Part 1, we covered the basic problem: pre-signed Lightning commitment transactions can have outdated fees by the time you need to broadcast them. Anchor outputs solve this by letting you boost fees later using CPFP (Child Pays For Parent).
Today, we're going deeper. We're answering the "why" and "how" questions that make anchor outputs actually work.
What we're covering in Part 2:
- How CPFP really works (the mechanics)
- Why 330 sats? (The magic number explained)
- The one-block delay (CSV) and why it's crucial
- What happens to your other outputs
- Real-world examples with actual numbers
Let's dive in.
CPFP Mechanics: How Does This Actually Work?
In Part 1, we learned that CPFP means "Child Pays For Parent." But let's understand the mechanics of HOW this works at the Bitcoin protocol level.
How Bitcoin Miners Think
Bitcoin miners want to maximize their profits. They look at transactions in the mempool and try to fill each block with the transactions that pay the highest fees.
Here's the key insight: Miners don't just look at individual transactions. They look at transaction packages (parent + child combinations) and calculate the total fee rate for the whole package.
The Math Behind It
Let's use real numbers:
Parent Transaction (Your Commitment TX):
- Size: 200 vbytes
- Fee: 200 sats (1 sat/vbyte)
- Fee rate: 1 sat/vbyte ❌ Too low!
This transaction alone won't get confirmed during high-fee periods. Miners will ignore it.
Now you create a Child Transaction:
- Size: 150 vbytes
- Spends: Your 330-sat anchor output
- Fee you add: 120,000 sats
- Total fee: 120,330 sats
Combined Package:
- Total size: 200 + 150 = 350 vbytes
- Total fees: 200 + 120,330 = 120,530 sats
- Package fee rate: 120,530 ÷ 350 = 344 sats/vbyte ✅
Now miners are interested! A 344 sat/vbyte fee rate is competitive even during high congestion.
The critical rule: The child transaction cannot be confirmed until the parent is confirmed (because the child spends an output from the parent). So miners MUST include both or neither.
This creates the economic incentive: to get the child's juicy fee, miners must also confirm the parent.
Why 330 Satoshis? The Magic Number Explained
You might be wondering: "Why exactly 330 sats? Why not 100 sats? Or 500 sats?"
Great question! There are actually three reasons for this specific number:
Reason 1: Bitcoin's Dust Limit
Bitcoin has something called a "dust limit" to prevent spam. Outputs that are too small are considered "dust" and many nodes won't relay transactions that create them.
The dust limit for standard outputs is around 546 satoshis.
But anchor outputs use a special script type that has a lower dust limit of 330 satoshis. This makes them the smallest spendable outputs possible without being classified as dust.
Why this matters: You want anchor outputs to be as small as possible so they don't waste channel capacity, but big enough to be spendable.
Reason 2: Standardization Across Lightning
All Lightning implementations (LND, Core Lightning, Eclair, LDK) agreed on 330 sats as the standard in the BOLT (Basis of Lightning Technology) specifications.
This means:
- Everyone uses the same amount
- Channels work consistently across different implementations
- No confusion or compatibility issues
Reason 3: Enough Value to Spend
Even though 330 sats is small (currently worth less than $0.50 USD), it's enough to:
- Be recognized as a valid output by the Bitcoin network
- Cover the cost of creating a small child transaction
- Not be dismissed as too trivial to process
The bottom line: 330 sats is the Goldilocks number—not too big (wastes channel funds), not too small (can't be spent), just right.
The One-Block Delay (CSV): Why Can't I Spend My Other Outputs Immediately?
Here's something interesting: When you broadcast a commitment transaction, you can spend your anchor output immediately, but you cannot spend your main balance output for at least one block (about 10 minutes).
This is called a CSV lock (CheckSequenceVerify).
What Is CSV?
CSV stands for CheckSequenceVerify. It's a Bitcoin script command that says: "This output cannot be spent until X blocks have been mined after this transaction is confirmed."
In anchor output commitment transactions, all outputs except the anchors have a 1 block CSV lock (written as 1 CSV in the script).
Why Does This Delay Exist?
This one-block delay prevents something called transaction pinning, which is a type of attack where your channel partner could try to interfere with your fee bumping.
Here's how the attack would work WITHOUT the CSV lock:
- You broadcast your commitment transaction with low fees
- Your evil partner immediately spends their balance output with a LOW fee
- This creates a competing transaction in the mempool
- When you try to CPFP using your anchor, Bitcoin's rules prevent you because there's already a conflicting spend
With the CSV lock:
- You broadcast your commitment transaction
- Your partner's balance output is locked for one block
- You can spend your anchor output immediately to boost fees
- Your commitment transaction confirms in the next block
- Only AFTER confirmation can your partner spend their output (but it's too late to interfere)
The CSV lock gives you a clean window to boost fees without interference.
What Happens to Your Other Outputs?
Let's map out ALL the outputs in a typical anchor output commitment transaction:
Output 1: Your Balance
- Amount: Your portion of the channel (e.g., 1,000,000 sats)
- Lock: 1 block CSV delay
- Why: This is your actual money from the channel
Output 2: Partner's Balance
- Amount: Their portion of the channel (e.g., 500,000 sats)
- Lock: 1 block CSV delay
- Why: This is their money from the channel
Output 3: Your Anchor
- Amount: 330 sats
- Lock: None! Can spend immediately
- Why: So YOU can fee-bump right away
Output 4: Partner's Anchor
- Amount: 330 sats
- Lock: None! Can spend immediately
- Why: So THEY can fee-bump right away
Optional Output 5: HTLCs (If Any)
- Amount: Varies (pending payments in the channel)
- Lock: Time-locked based on payment conditions
- Why: These are in-flight payments that need to be resolved
Key takeaway: Only the anchor outputs can be spent immediately. Everything else waits one block. This is by design for security.
Real-World Example: The Numbers in Action
Let's walk through a complete real-world scenario with actual numbers to see how this all works together.
The Setup
You have a Lightning channel:
- Your balance: 5,000,000 sats (0.05 BTC)
- Partner balance: 3,000,000 sats (0.03 BTC)
- Your anchor: 330 sats
- Partner anchor: 330 sats
Total channel capacity: 8,000,660 sats
The Crisis
Your partner goes offline. You need to force-close the channel to get your funds back.
You check Bitcoin mempool fees:
- Current rate: 250 sats/vbyte (high congestion!)
- Your commitment transaction size: 220 vbytes
- Needed fee: 220 × 250 = 55,000 sats
Problem: Your pre-signed commitment only has a 440 sat fee (2 sats/vbyte). This won't confirm for days or weeks.
The Solution: CPFP
Step 1: Broadcast commitment transaction
- Fee paid: 440 sats (pathetically low)
- Status: Sitting in mempool, unconfirmed
Step 2: Create child transaction
You create a new transaction that:
- Spends: Your 330-sat anchor output
- Adds inputs: 60,000 sats from your regular Bitcoin wallet
- Creates output: Sends to your wallet
- Transaction size: 180 vbytes
- Fee: 54,560 sats + 330 sats (anchor) = 54,890 sats total
Step 3: Calculate package fee rate
- Parent size: 220 vbytes
- Child size: 180 vbytes
- Total size: 400 vbytes
- Parent fee: 440 sats
- Child fee: 54,890 sats
- Total fee: 55,330 sats
- Package rate: 55,330 ÷ 400 = 138 sats/vbyte
Wait, that's still lower than the 250 sats/vbyte market rate! Let me recalculate...
Step 2 (corrected): Create child transaction with proper fees
You need the package to average 250 sats/vbyte:
- Total needed: 400 vbytes × 250 = 100,000 sats
- Parent already paid: 440 sats
- Child must pay: 100,000 - 440 = 99,560 sats
So you create the child transaction with a 99,560 sat fee.
Step 3 (corrected): Final package
- Total size: 400 vbytes
- Total fees: 440 + 99,560 = 100,000 sats
- Package rate: 250 sats/vbyte ✅
Step 4: Confirmation
Miners see your attractive package and include it in the next block. Both transactions confirm together.
The cost:
- You paid 100,000 sats total (~$130 USD at $65k BTC)
- But you secured your 5,000,000 sats (0.05 BTC = ~$3,250 USD)
- Worth it!
The Economics: Is This Expensive?
Let's talk about the elephant in the room: This can be expensive!
When Fees Are Normal (1-10 sats/vbyte)
- Your commitment TX: 220 vbytes × 5 = 1,100 sats (~$1.43)
- CPFP child: 180 vbytes × 5 = 900 sats (~$1.17)
- Total cost: ~$2.60 ✅ Very affordable!
When Fees Are High (200+ sats/vbyte)
- Your commitment TX: 220 vbytes × 200 = 44,000 sats (~$57)
- CPFP child: 180 vbytes × 200 = 36,000 sats (~$47)
- Total cost: ~$104 ⚠️ Ouch!
When Fees Are INSANE (500+ sats/vbyte)
- Your commitment TX: 220 vbytes × 500 = 110,000 sats (~$143)
- CPFP child: 180 vbytes × 500 = 90,000 sats (~$117)
- Total cost: ~$260 💀 Very painful!
The reality: Force-closing channels during high-fee periods is expensive. This is why:
- Lightning encourages cooperative closes (much cheaper)
- You should maintain channels with reliable partners
- Reserve funds for fee-bumping are essential
But here's the key: Without anchor outputs, you might not be able to close at all during high-fee periods. You'd be completely stuck. Anchor outputs give you the OPTION to pay more to get your funds back—which is better than having no option.
Common Questions
Q: Can I use the same anchor output multiple times?
A: No! Once you spend an anchor output in a child transaction, that's it. You can't spend it again. If your child transaction doesn't have enough fee and still doesn't confirm, you'd need to create ANOTHER child transaction that spends the FIRST child (a "grandchild") to bump fees further. This is called CPFP chaining.
Q: What if my partner also tries to fee-bump at the same time?
A: That's fine! You each have your own separate anchor output. You can both create child transactions independently. Whichever child transaction (yours or theirs) gets confirmed first will pull the parent through. This is actually good—it means either party can ensure confirmation.
Q: What if I don't have enough Bitcoin to fee-bump?
A: Then you're stuck. This is why maintaining a reserve fund is crucial. If you operate Lightning channels, you MUST keep separate on-chain Bitcoin available for fee-bumping emergencies. Think of it as insurance—you pay a little to protect a lot.
Q: Can I spend my balance output and my anchor in the same transaction?
A: No! Your balance output has a 1-block CSV lock. You must wait one block after the commitment transaction confirms before you can spend your balance. The anchor can be spent immediately, but the balance cannot.
Q: Why can't commitment transactions just use RBF (Replace-By-Fee) instead?
A: Great question! RBF (Replace-By-Fee) allows you to replace an unconfirmed transaction with a new version that pays higher fees. However, RBF doesn't work well for Lightning because:
- Both parties would need to cooperate to create the replacement (but in a force-close, your partner is unresponsive)
- RBF is vulnerable to transaction pinning attacks
- CPFP with anchors is more secure because each party can act independently
What We've Learned in Part 2
Let's recap the key technical details we covered:
✅ CPFP mechanics: Miners calculate package fee rates (parent + child together), creating the economic incentive to confirm both
✅ 330 sats explained: The minimum spendable amount that's not classified as dust, standardized across all Lightning implementations
✅ CSV lock: The one-block delay on balance outputs prevents transaction pinning attacks and gives you a clean window to fee-bump
✅ Output structure: Anchors can be spent immediately, but all other outputs must wait one block after confirmation
✅ Real costs: Can range from $3 in normal times to $200+ during extreme congestion—but it beats being stuck with no option
✅ Economics: Force-closing is expensive, which incentivizes cooperative closes and choosing reliable channel partners
What's Coming in Part 3
Now that you understand the technical details, Part 3 will cover the practical side:
- How to check if your Lightning node supports anchor outputs
- Setting up anchor outputs in different implementations (LND, Core Lightning, Eclair)
- How much Bitcoin to keep in reserve for fee-bumping
- Tools and commands for monitoring and managing anchor outputs
- What to do when a force-close happens
Building Understanding Together
We've gone from "what are anchor outputs?" (Part 1) to "how do they actually work?" (Part 2). The complexity is increasing, but we're building on the foundation step by step.
If anything in Part 2 was confusing, that's valuable feedback for me. It helps me understand what needs more explanation.
Next up: Part 3 will be hands-on and practical. We'll move from theory to "okay, how do I actually USE this stuff?"
Thanks for sticking with me through the technical details. See you in Part 3.
Quick Summary (For the Skimmers)
- CPFP works because miners calculate package fee rates (parent + child together)
- 330 sats is the smallest spendable amount that's not dust, standardized in BOLT specs
- CSV lock (1 block delay) on balance outputs prevents transaction pinning attacks
- Only anchors can be spent immediately; all other outputs wait 1 block
- Real costs vary from $3 to $200+ depending on network congestion
- Part 3 coming: Practical setup, implementation guides, and reserve fund management
If you have any questions or feedback? Drop them in the comments
Top comments (0)