NotATether: Create Anchor output stub (LN option_anchors vs P2A / ephemeral)

2026-09-12T04:45:50Z

Create Anchor output stub (LN option_anchors vs P2A / ephemeral)

New page

An '''anchor output''' is a small transaction output left on a presigned transaction so a later child-pays-for-parent spend can attach fees at broadcast time. On the [[Lightning Network]], BOLT 3 <code>option_anchors</code> uses two '''keyed''' P2WSH anchors (typically 330 satoshis each). That design is distinct from [[Pay-to-anchor]] (P2A), which is a keyless native segwit output template (BIP 433), and from an [[Ephemeral_anchor|ephemeral anchor]], which is a usage pattern that creates and spends a P2A output in the same unconfirmed [[TRUC]] package so it never persists in the UTXO set.

A Lightning commitment is signed long before either party broadcasts it. If the commitment pays too low a feerate it may not confirm in time; if it pays too high, the parties overpay. Signing many feerate variants is unwieldy. Leaving the commitment underpaying and attaching a child that spends an output of the commitment lets fees be chosen later. Ordinary mempool descendant limits can still be exhausted by a counterparty who attaches many descendants, blocking child-pays-for-parent. Bitcoin Core's CPFP carve-out granted one extra descendant under conditions Lightning met by giving each party its own small keyed anchor.

Under <code>option_anchors</code>, each commitment includes <code>to_local_anchor</code> and <code>to_remote_anchor</code>. Each is a P2WSH whose witness script requires that party's funding key, or after 16 blocks any spend (<code>OP_16 CHECKSEQUENCEVERIFY</code>). The owner can spend immediately to fee-bump; after 16 blocks anyone can sweep an abandoned anchor. Two keyed anchors exist so one party cannot occupy the only fee-bumping output. The commitment itself still usually pays a modest fee so it is not entirely dependent on the child.

Keyed anchors add weight on every commitment, require a UTXO to fund the child, can litter the UTXO set if unswept, and depend on CPFP carve-out (not granted to TRUC transactions and removed with cluster mempool in Bitcoin Core 31.0). Protocols that need a guaranteed fee-bump path on that stack are expected to migrate toward TRUC packages and a single shared P2A / ephemeral-anchor style output. Some deployments still use keyed anchors when peers do not relay TRUC packages or when only a designated key should attach fees.

== See also ==
* [[Ephemeral_anchor|Ephemeral anchor]]
* [[Pay-to-anchor]]
* [[TRUC]]
* [[Lightning Network]]
* [[Package relay]]
* [[Replace by fee]]

== External links ==
* [https://github.com/lightning/bolts/blob/master/03-transactions.md BOLT 3: Bitcoin Transaction and Script Formats]
* [https://bitcoinops.org/en/topics/ephemeral-anchors/ Bitcoin Optech: Ephemeral anchors]
* [https://github.com/bitcoin/bips/blob/master/bip-0433.mediawiki BIP 433: Pay to Anchor (P2A)]

[[Category:Technical]]

Anchor output - Revision history

NotATether: Create Anchor output stub (LN option_anchors vs P2A / ephemeral)