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

Source: Dev.to

Welcome back, and thank you for being here to learn with me.

Recap: Part 1

• Problem: Pre‑signed Lightning commitment transactions can have outdated fees by the time you need to broadcast them.
• Solution: Anchor outputs let you boost fees later using CPFP (Child Pays For Parent).

What We’ll Cover in Part 2

1. How CPFP really works – the mechanics at the Bitcoin protocol level.
2. Why 330 sats? – the “magic number” explained.
3. The one‑block delay (CSV) – why it’s crucial for security.
4. What happens to your other outputs – a quick overview.
5. Real‑world examples with actual numbers.

1. CPFP Mechanics

The basic idea

• Miners want to maximize profit, so they fill each block with the highest‑fee transactions.
• They consider transaction packages (parent + child) and compute a combined fee rate.

Example with real numbers

• The child transaction cannot be confirmed until the parent is confirmed (it spends an output from the parent).
• Miners must include both or neither, so the high fee in the child pulls the parent into the block.

2. Why 330 sats?

1. Dust limit – Bitcoin rejects outputs that are too small to be economical.
   • Standard dust limit ≈ 546 sats.
2. Anchor‑output script – a special script type with a lower dust limit of 330 sats, making it the smallest spendable output that isn’t considered dust.
3. Consensus – All major Lightning implementations (LND, Core Lightning, Eclair, LDK) adopted 330 sats in the BOLT specifications, ensuring compatibility.

Why this number is “just right”

• Small enough not to waste channel capacity.
• Large enough to be recognized as a valid output and to cover the cost of a tiny child transaction.

The example below is truncated in the original draft; feel free to fill in the missing values as needed.

You have a Lightning channel:

• Your balance: 5,0… (value continues in the original text)

(Continue the walkthrough with the actual numbers you wish to illustrate.)

TL;DR

• CPFP works because miners evaluate the combined fee rate of parent + child packages.
• 330 sats is the smallest non‑dust, spendable output for anchors, standardized across implementations.
• A 1‑block CSV lock on all non‑anchor outputs prevents adversarial “pinning” attacks and gives you a safe window to bump fees.
• Only anchor outputs are immediately spendable; everything else is delayed by one block for security.

Channel Overview

Your partner goes offline, so you must force‑close the channel to retrieve your funds.

1️⃣ Check the mempool fee market

• Current fee rate: 250 sats/vbyte (high congestion)
• Commitment transaction size: 220 vbytes
• Required fee for confirmation: 220 × 250 = 55,000 sats

Problem: Your pre‑signed commitment transaction only includes a 440 sat fee (≈ 2 sats/vbyte). At the current market rate it would sit in the mempool for days or weeks.

2️⃣ Broadcast the commitment transaction

• Fee paid: 440 sats (far too low)
• Status: Unconfirmed, stuck in the mempool

3️⃣ Create a CPFP child transaction

3.1 Calculate the package fee rate (parent + child)

• Parent size: 220 vbytes
• Child size: 180 vbytes
• Total size: 400 vbytes

• Package rate: 55,330 ÷ 400 ≈ 138 sats/vbyte

This is still below the required 250 sats/vbyte.

4️⃣ Re‑calculate the child fee to meet the market rate

1. Target total fee: 400 vbytes × 250 sats/vbyte = 100,000 sats
2. Parent already paid: 440 sats
3. Child must pay: 100,000 – 440 = 99,560 sats

Create the child transaction with a 99,560 sat fee.

4.1 Final package

• Package rate: 100,000 ÷ 400 = 250 sats/vbyte ✅

5️⃣ Confirmation & Cost Summary

• Total on‑chain cost: 100,000 sats ≈ $130 USD (at $65 k/BTC)
• Funds secured: 5,000,000 sats (0.05 BTC ≈ $3,250 USD)

Result: Paying the fee is worthwhile to recover your funds.

6️⃣ Fee Scenarios (illustrative)

Force‑closing during high‑fee periods can be expensive, which is why Lightning encourages cooperative closes.

7️⃣ Why Anchor Outputs Matter

• Without anchors you may be unable to close a channel during fee spikes (the parent transaction would never confirm).
• With anchors you have the option to add fees via CPFP, giving you a path to recover funds.

Common Q&A

8️⃣ Key Take‑aways

• CPFP mechanics: Miners evaluate the combined fee rate of parent + child, incentivizing them to confirm both.
• 330 sats anchor: The minimum non‑dust spendable amount, standardized across Lightning implementations.
• CSV lock: A 1‑block delay on balance outputs prevents transaction‑pinning attacks and gives a clean window for fee‑bumping.
• Cost spectrum: From a few dollars in normal times to hundreds during extreme congestion – still cheaper than being stuck.
• Economic incentive: High force‑close costs push users toward cooperative closes and reliable channel partners.

9️⃣ What’s Next? (Part 3 – Practical Guide)

1. Check if your node supports anchor outputs (LND, Core Lightning, Eclair).
2. Enable/disable anchor outputs in each implementation.
3. Reserve funds: How much on‑chain Bitcoin to keep for emergency fee‑bumping.
4. Tools & commands for monitoring anchor outputs and fee‑bumping.
5. Step‑by‑step actions when a force‑close occurs.

We’ve moved from “what are anchor outputs?” (Part 1) → “how do they work?” (Part 2) → hands‑on usage (Part 3).

If any part of Part 2 was confusing, let me know—your feedback helps improve the explanations.

See you in Part 3!

CSV Lock (1‑Block Delay) on Balance Outputs Prevents Transaction Pinning Attacks

• Only anchors can be spent immediately; all other outputs must wait 1 block.
• Real costs vary from $3 to $200+ depending on network congestion.

Coming Next (Part 3)

• Practical setup
• Implementation guides
• Reserve‑fund management

If you have any questions or feedback, drop them in the comments.