This is Part 1 of an ongoing series where I'm learning about Lightning Network anchor outputs and sharing what I discover along the way.
A Note Before We Start
Hi! I'm learning about Lightning Network anchor outputs and documenting my journey. This is going to be a continuous series where I break down complex topics into digestible pieces.
Why a series? Because this stuff is complicated, and trying to explain everything at once would be overwhelming, both for me to write and for you to read. So, we're taking it step by step, together.
What to expect:
- Part 1 (this article): The basic problem and what anchor outputs are
- Part 2 (coming next): How they actually work in detail
- Part 3+: Implementation, setup, management, and real-world usage
Let's build this understanding together, one piece at a time.
The Problem We're Solving
We use the Lightning Network for quick and low-cost Bitcoin payments. But there's a challenge: if a channel closes unexpectedly, changing network fees can cause transactions to get stuck and delay your funds.
Here's the scenario:
You open a Lightning channel today when Bitcoin network fees are low (let's say 5 sats/vbyte). You and your channel partner sign some special transactions called "commitment transactions" that say "if we need to close this channel, here's who gets what."
The problem? These transactions are signed TODAY, but you might not need to use them until WEEKS or MONTHS later.
What happens then?
Week 1: Channel opens, fees are 5 sats/vbyte
Week 4: You need to close the channel, but now fees are 500 sats/vbyte
**Result: **Your transaction with the old 5 sats/vbyte fee sits in the waiting room (mempool) forever because miners prioritize higher-paying transactions
You're stuck. Your funds are in limbo because you guessed wrong about future fees.
This is the exact problem anchor outputs solve.
What Are Lightning Network Anchor Outputs?
Picture this: You're vibing with your Lightning channel, everything's smooth, then BAM—network fees spike and your transaction gets stuck. You're basically Mort from Madagascar watching the fossa approach—complete panic mode.
Anchor outputs are the solution. Think of them like the assistance service you use at a mall when you forget where you parked your car:
The Mall Parking Analogy
WITHOUT Anchor Outputs:
You pay for parking when you enter (5 shillings, based on last month's rate). Three weeks later when you're ready to leave, parking now costs 50 shillings. The attendant won't let you out because you paid the old rate. You're stuck in the parking lot.
WITH Anchor Outputs:
You get a basic ticket when you enter (minimal fee). When you're ready to leave and see parking now costs 50 shillings, you can pay the CURRENT rate right then and there. The attendant is happy, you leave smoothly, everyone wins.
That's what anchor outputs do for Lightning channels.
Instead of guessing what fees will be weeks from now, you pay a tiny amount upfront and can boost the fee to whatever is needed when you actually close the channel.
What Exactly Are Anchor Outputs?
Anchor outputs are tiny Bitcoin outputs (around 330 satoshis) that get attached to your commitment transaction. They exist for ONE purpose: to let you boost your transaction fee later using CPFP.
Think of them as handles or hooks attached to your transaction that you can grab onto later to pull it through when you need to.
How This Works (Step by Step)
Step 1: Opening the Channel
When you create a Lightning channel with anchor outputs enabled, your commitment transaction includes:
- Your balance output - Your portion of the channel funds
- Partner's balance output - Their portion of the channel funds
- Your anchor output - 330 sats that YOU can spend
- Partner's anchor output - 330 sats that THEY can spend
Both of you get your own anchor. This means either person can boost fees independently.
Step 2: Channel Needs to Close
Something happens—maybe your partner goes offline, maybe there's a dispute—and you need to broadcast your commitment transaction to close the channel (a "force close").
Step 3: Check Current Fees
You look at the Bitcoin network. Fees are HIGH. Your pre-signed commitment transaction only has a minimal fee (maybe 1-2 sats/vbyte). At current rates, it won't confirm for days or weeks.
Step 4: CPFP to the Rescue
This is where the magic happens:
- You create a NEW transaction (the "child")
- This child transaction spends your 330-sat anchor output
- You add a LARGE fee to this child transaction (from your regular Bitcoin wallet)
- Miners see: "If I confirm the parent (your commitment tx), I get to also confirm the child and collect that big fee!"
- Both transactions get confirmed together
You've successfully boosted your commitment transaction's fee AFTER broadcasting it.
Visual Breakdown
Here's what it looks like:
PARENT TRANSACTION (Your Commitment Transaction)
┌─────────────────────────────────────────────────┐
│ Your balance: 1,000,000 sats │
│ Partner's balance: 500,000 sats │
│ Your anchor: 330 sats ⚓ ← YOU GRAB THIS │
│ Partner's anchor: 330 sats ⚓ │
│ │
│ Fee: 1 sat/vbyte (very low) │
└─────────────────────────────────────────────────┘
↓
(You create a child transaction)
↓
CHILD TRANSACTION
┌─────────────────────────────────────────────────┐
│ Spends: Your 330-sat anchor output │
│ Adds: 50,000 sats from your wallet │
│ Total Fee: 50,330 sats (300+ sats/vbyte) │
│ │
│ Miners: "Great fee! We'll confirm BOTH!" │
└─────────────────────────────────────────────────┘
↓
BOTH CONFIRMED! ✅
That's Part 1!
What we covered today:
- The fee guessing problem with Lightning channels
- What anchor outputs are (tiny 330-sat outputs for fee bumping)
- The mall parking analogy
- The four-step process of how anchor outputs work
- A visual diagram of parent and child transactions
What's coming in Part 2:
- Deep dive into CPFP mechanics
- Why anchor outputs are 330 sats specifically
- What happens to the other outputs in commitment transactions
- The one-block delay (CSV) and why it matters
- Real-world examples with actual numbers
Building This Series Together
I'm learning this stuff as I go, breaking it down into pieces that make sense to me, and sharing it with you. If something's unclear, that helps me learn where I need to explain better in future parts.
This is a continuous series. I'm not trying to teach everything at once. We're building understanding brick by brick.
Next up: Part 2 will go deeper into the technical details and answer questions like "why 330 sats?" and "what prevents my channel partner from messing with my fee bump?"
Thanks for learning with me. See you in Part 2!
Quick Summary (If You're Skimming)
- Problem: Lightning channels use pre-signed transactions, but fees might change by the time you need to close
- Solution: Anchor outputs let you boost fees AFTER broadcasting using CPFP
- How: Tiny 330-sat outputs attached to commitment transactions that you can spend to create a high-fee child transaction
- Analogy: Like paying for mall parking when you LEAVE instead of guessing the fee weeks earlier
Part 2 coming next where we go deeper!


Top comments (0)