DEV Community

Susan Githaiga
Susan Githaiga

Posted on

Lightning Network Anchor Outputs Explained: The Basics (Part 1)

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.

Lightning Network Anchor Outputs

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.

Lightning Network Anchor Outputs

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:

  1. Your balance output - Your portion of the channel funds
  2. Partner's balance output - Their portion of the channel funds
  3. Your anchor output - 330 sats that YOU can spend
  4. 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:

  1. You create a NEW transaction (the "child")
  2. This child transaction spends your 330-sat anchor output
  3. You add a LARGE fee to this child transaction (from your regular Bitcoin wallet)
  4. Miners see: "If I confirm the parent (your commitment tx), I get to also confirm the child and collect that big fee!"
  5. 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! ✅
Enter fullscreen mode Exit fullscreen mode

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)