Anchor Outputs

What Are Anchor Outputs?

Anchor outputs are special outputs added to Lightning Network commitment transactions that enable dynamic fee adjustment after the transaction is broadcast. Each commitment transaction includes two small anchor outputs, one controlled by each channel party, which can be spent to attach additional fees via Child Pays for Parent (CPFP).

The name "anchor" reflects their purpose: these outputs anchor the commitment transaction to the blockchain by providing a mechanism to pay whatever fee is necessary for timely confirmation. Without anchors, commitment transactions are broadcast with pre-signed fees that may be insufficient during fee spikes.

Anchor outputs were introduced in BOLT 3 as an optional commitment format and have become the recommended standard for new Lightning channels. They represent a fundamental improvement in channel security, particularly for the force close scenario where time-sensitive transactions must confirm within specific windows.

The Fee Volatility Problem

To understand why anchor outputs matter, consider how Lightning commitment transactions originally worked. When two parties open a channel, they pre-sign commitment transactions that can close the channel unilaterally. These transactions must include a fee, but that fee is locked in at signing time.

Bitcoin fees are volatile. A fee that seemed reasonable when the commitment was signed might be far too low weeks or months later during a fee spike. This creates a dangerous scenario:

• Stuck force closes: If you need to force close during high fees, your commitment transaction might not confirm for hours or days.
• HTLC timeout attacks: HTLCs have time locks. If your commitment transaction is stuck, pending HTLCs might expire before your transaction confirms, allowing your counterparty to claim funds that should be yours.
• Justice transaction delays: If your counterparty broadcasts an old commitment (attempting theft), you need to broadcast a penalty transaction quickly. High fees could delay your response.

The original solution was fee negotiation: channel parties would periodically update commitment transaction fees. But this required both parties to be online and cooperative, precisely the conditions that might not exist when you need to force close.

How Anchor Outputs Work

Anchor outputs solve the fee problem by separating fee payment from the commitment transaction itself. The commitment transaction is broadcast with a minimal fee (or zero fee in newer implementations), and fees are added through a child transaction that spends the anchor output.

The CPFP Mechanism

Child Pays for Parent is a Bitcoin mempool policy where miners consider the combined fee rate of a parent transaction and its children. If a parent has low fees but a child spends one of its outputs with high fees, miners are incentivized to include both transactions to collect the total fee.

With anchor outputs, the flow works like this:

1. Broadcast commitment: The commitment transaction is broadcast with its pre-signed (potentially low) fee.
2. Assess confirmation: If the transaction is not confirming quickly enough, action is needed.
3. Create child transaction: Spend the anchor output in a child transaction with a high fee.
4. Miners include both: Miners see the combined fee rate and include both the commitment and the fee-bumping child transaction.

Two Anchors, Two Parties

Commitment transactions include two anchor outputs because either party might need to fee bump. If only one anchor existed, controlled by one party, the other party would be helpless during a dispute. With two anchors:

• If Alice broadcasts the commitment, she can use her anchor to fee bump.
• If Bob sees the commitment and it is not confirming, he can use his anchor to fee bump, even though Alice broadcast the transaction.

This symmetry ensures neither party can hold the other hostage during a fee spike.

Technical Implementation

Anchor outputs have specific technical requirements that enable CPFP while preventing abuse.

Output Structure

Each anchor output is 330 satoshis (the dust limit for P2WSH outputs) and uses a specific script structure:

# Anchor output script (simplified)
<local_pubkey> OP_CHECKSIG OP_IFDUP OP_NOTIF
  OP_16 OP_CHECKSEQUENCEVERIFY
OP_ENDIF

This script allows the anchor owner to spend immediately, but after 16 blocks, anyone can spend it. This cleanup mechanism prevents tiny anchor outputs from polluting the UTXO set forever.

Carve-Out Rule

Bitcoin Core includes a special mempool policy called the "CPFP carve-out" that was added specifically for anchor outputs. Normally, transaction packages have strict limits on descendant transactions. The carve-out allows one additional small child transaction beyond these limits, ensuring both channel parties can create fee-bumping children even if one party has already attached descendants.

# Bitcoin Core mempool rules allow:
# - Standard descendant limits (25 transactions, 101 KB)
# - Plus one additional small carve-out transaction
# This ensures both anchor outputs can be spent

HTLC Handling

With anchor outputs, HTLC outputs in commitment transactions are modified to use SIGHASH_SINGLE | SIGHASH_ANYONECANPAY signatures. This allows HTLC claims to be fee-bumped independently if needed, providing additional flexibility beyond just the anchor outputs.

Evolution of Anchor Outputs

Original Anchor Outputs

The first anchor output specification added two 330-sat outputs to each commitment transaction. While effective, this added 660 satoshis of overhead per commitment, which accumulated across many channel updates.

Zero-Fee Anchor Outputs

The current standard, sometimes called "zero-fee anchors" or "simplified anchors," sets the commitment transaction fee to zero and relies entirely on CPFP for fee payment. This approach:

• Eliminates fee guessing entirely since all fees come from CPFP.
• Simplifies channel state since no fee negotiations are needed.
• Requires nodes to maintain fee-bumping reserves (UTXOs for CPFP spending).

Future: Ephemeral Anchors

Proposed improvements like ephemeral anchors would allow zero-value anchor outputs that must be spent in the same block. This eliminates the 330-sat dust overhead while maintaining CPFP capability. Ephemeral anchors require Bitcoin consensus changes and are part of ongoing protocol development discussions.

Security Considerations

Reserve Requirements

Anchor outputs shift fee responsibility to the time of broadcast. This means nodes must maintain confirmed UTXOs specifically for fee bumping. A node without available UTXOs cannot effectively fee bump, potentially recreating the stuck transaction problem. Wallet implementations should maintain fee-bumping reserves and alert operators when reserves are low.

Pinning Attacks

Transaction pinning is an attack where a malicious party attaches large, low-fee descendants to a transaction, making it expensive to fee bump. The CPFP carve-out mitigates this for anchor outputs, but operators should understand that sophisticated attackers might attempt pinning strategies. Package relay improvements in Bitcoin Core continue to address these attack vectors.

Anchor Cleanup

The 16-block anyone-can-spend mechanism prevents UTXO bloat but means small amounts in anchors could theoretically be claimed by third parties. In practice, this is not a security concern since anchor values are at dust level, but implementations should not rely on recovering anchor funds.

Channel Type Negotiation

Lightning nodes negotiate channel types during opening. Not all nodes support anchor outputs, and channels may fall back to legacy commitment formats when connecting to older implementations. For maximum security, operators should prefer peers that support anchor outputs and monitor their channel types.

FAQ