Home › Glossary › Anchor output

Anchor output

Also called: anchor outputs, anchors, P2A, pay to anchor, ephemeral anchors.

An anchor output is a small extra output on a pre-signed transaction that can be spent by a CPFP child to add fees when the transaction is broadcast.

An anchor output is an output added to a pre-signed transaction purely so that its fee can be raised later. Protocols like the Lightning Network sign transactions long before they might be broadcast, when nobody knows what fee rate will be needed. An anchor gives a party an output they can spend right away with a high-fee child transaction, bumping the parent through child pays for parent.

Keyed anchors in Lightning

Lightning's anchor channel format adds two small anchor outputs to each commitment transaction, one per party, each spendable with that party's key. To stop one side from using mempool descendant limits to block the other's child, these channels rely on Bitcoin Core's "CPFP carve-out" exception. BIP 431 explains why that exception doesn't fit the newer cluster mempool design and offers TRUC transactions instead.

Pay to Anchor (P2A)

BIP 433, by Gregory Sanders, defines a standard keyless anchor:

  • the scriptPubKey is OP_1 followed by the two bytes 0x4e73, a witness version 1 program that spells "fees" in bech32m (mainnet address bc1pfeessrawgf);
  • it is spent with an empty witness, so no signature is needed and anyone can bump the fee;
  • both the output and the input that spends it are small, saving block space.

Because anyone can attach a child, BIP 433 suggests using P2A with TRUC transactions (BIP 431), which cap the child at 1,000 vB to prevent pinning. Under "ephemeral dust" policy the anchor can even hold zero value, as long as the parent pays no fee and the anchor is spent in the same package. Together these ideas are known as ephemeral anchors, and they rely on package relay to propagate.

BIPs that define Anchor output

  • BIP 433: Pay to Anchor (P2A): Draft. Defines Pay to Anchor, a tiny standard output that anyone can spend without a signature. Its purpose is to act as a hook for fee-bumping: by spending it in a follow-up transaction, any party can add…
  • BIP 431 (TRUC transactions): Topology Restrictions for Pinning: Draft. Explains 'pinning', a problem where someone can block a transaction from being replaced with a higher-fee version, which can endanger time-sensitive protocols like Lightning. It describes stricter…
  • BIP 331: Ancestor Package Relay: Draft. Lets nodes request and share an unconfirmed transaction together with the parent transactions it depends on, as a single package. This helps low-fee parents get relayed when a child pays extra fees…

Related terms

  • Child pays for parent (CPFP): Child pays for parent (CPFP) speeds up a stuck transaction by spending one of its outputs in a new high-fee transaction, so miners confirm both together.
  • Package relay: Package relay lets Bitcoin nodes accept and relay related unconfirmed transactions together, so a high-fee child can carry a low-fee parent.
  • Lightning Network: The Lightning Network is a layer-2 payment network on Bitcoin: users pay through chains of off-chain channels and settle on-chain only when needed.
  • Dust: Dust is a bitcoin output so small that spending it would cost more in fees than it's worth. Nodes don't relay transactions that create it by default.

Learn more

Guides