Anchor output - Revision history

NotATether: Add option_anchors and Migration sections

2026-09-13T07:30:14Z

Add option_anchors and Migration sections

← Older revision		Revision as of 07:30, 13 September 2026
Line 1:		Line 1:
	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.		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.

			== option_anchors ==

	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.		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.		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.

			When a commitment is broadcast, the owning party builds a child that spends its keyed anchor into fees and any change. The child must satisfy ordinary standardness and, on older Core versions, fit under descendant limits with the carve-out exception. After cluster mempool removed carve-out, a second child competing for the same parent can fail relay even when both parties act honestly. That is a primary reason newer designs prefer a single shared [[Pay-to-anchor]] output inside a [[TRUC]] package.

			BOLT 3 also defines trimmed HTLC outputs that fall below the dust threshold when fees rise. Anchors do not replace those trim rules. They only provide a place to attach fees after the fact. Peers negotiate <code>option_anchors</code> (and related bits such as <code>option_scid_alias</code> in other contexts) during channel establishment. A channel without the feature falls back to committing an explicit fee at signing time.

			== Migration ==

	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.		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.

	~~When a commitment is broadcast, the owning party builds a child~~ that ~~spends its~~ keyed ~~anchor into fees and any change~~. ~~The child must satisfy ordinary standardness and, on older Core versions, fit under descendant limits~~ with ~~the~~ carve-out exception. After cluster mempool removed carve-out, a second child competing for the same parent can fail relay even when both parties act honestly. That is a primary reason newer designs prefer a single shared [[Pay-to-anchor]] ~~output inside a [[TRUC]] package~~.		Channels that still negotiate only keyed anchors remain interoperable with older peers. Dual support during upgrade means a node may fee-bump with carve-out logic toward one peer and with TRUC and [[Pay-to-anchor]] toward another.

	BOLT 3 also defines trimmed HTLC outputs that fall below the dust threshold when fees rise. Anchors do not replace those trim rules. They only provide a place to attach fees after the fact. Peers negotiate <code>option_anchors</code> (and related bits such as <code>option_scid_alias</code> in other contexts) during channel establishment. A channel without the feature falls back to committing an explicit fee at signing time.

	== See also ==		== See also ==

NotATether: Expand See also links

2026-09-13T07:19:15Z

Expand See also links

← Older revision		Revision as of 07:19, 13 September 2026
Line 15:		Line 15:
	* [[Pay-to-anchor]]		* [[Pay-to-anchor]]
	* [[TRUC]]		* [[TRUC]]
			* [[Cluster mempool]]
	* [[Lightning Network]]		* [[Lightning Network]]
	* [[Package relay]]		* [[Package relay]]

NotATether: Add BOLT trim relation and feature negotiation

2026-09-13T07:19:14Z

Add BOLT trim relation and feature negotiation

← Older revision		Revision as of 07:19, 13 September 2026
Line 8:		Line 8:

	When a commitment is broadcast, the owning party builds a child that spends its keyed anchor into fees and any change. The child must satisfy ordinary standardness and, on older Core versions, fit under descendant limits with the carve-out exception. After cluster mempool removed carve-out, a second child competing for the same parent can fail relay even when both parties act honestly. That is a primary reason newer designs prefer a single shared [[Pay-to-anchor]] output inside a [[TRUC]] package.		When a commitment is broadcast, the owning party builds a child that spends its keyed anchor into fees and any change. The child must satisfy ordinary standardness and, on older Core versions, fit under descendant limits with the carve-out exception. After cluster mempool removed carve-out, a second child competing for the same parent can fail relay even when both parties act honestly. That is a primary reason newer designs prefer a single shared [[Pay-to-anchor]] output inside a [[TRUC]] package.

			BOLT 3 also defines trimmed HTLC outputs that fall below the dust threshold when fees rise. Anchors do not replace those trim rules. They only provide a place to attach fees after the fact. Peers negotiate <code>option_anchors</code> (and related bits such as <code>option_scid_alias</code> in other contexts) during channel establishment. A channel without the feature falls back to committing an explicit fee at signing time.

	== See also ==		== See also ==

NotATether: Add mechanism: CPFP child and carve-out removal

2026-09-13T07:19:12Z

Add mechanism: CPFP child and carve-out removal

← Older revision		Revision as of 07:19, 13 September 2026
Line 6:		Line 6:

	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.		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.

			When a commitment is broadcast, the owning party builds a child that spends its keyed anchor into fees and any change. The child must satisfy ordinary standardness and, on older Core versions, fit under descendant limits with the carve-out exception. After cluster mempool removed carve-out, a second child competing for the same parent can fail relay even when both parties act honestly. That is a primary reason newer designs prefer a single shared [[Pay-to-anchor]] output inside a [[TRUC]] package.

	== See also ==		== See also ==

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]]