Glossary / Protocol & upgrades
Ephemeral anchor
- Definition
- An ephemeral anchor is a zero-value output added to a transaction purely so that somebody can attach a fee-paying child and drag the parent into a block.
Specified in BIP-431.
Contract protocols such as Lightning must sign transactions long before anyone knows what fees will be, so they need a way to top the fee up later. Bitcoin Core 28.0 made a four byte anyone-can-spend script standard for exactly that job, and 29.0 allowed such an output to hold nothing at all provided its parent pays no fee. The payoff is channel closes that cost less and strand less.
How it works
An ephemeral anchor solves a scheduling problem: a presigned transaction carries a fee rate chosen months before it is broadcast, and by the time it is needed the market has moved.
The older workaround gave the transaction a small spendable output and let whoever needed it broadcast a child paying for both. Lightning's anchor channels do this with two outputs of 330 satoshis, one per party. It works, but that money is committed inside every commitment transaction, and the outputs sit in the set of live coins afterwards whether anyone sweeps them or not.
Pay-to-anchor removed most of that cost. Bitcoin Core 28.0 recognised a new standard output whose script is exactly four bytes: OP_1, a two byte push, and the bytes 0x4e 0x73. That is a segwit version 1 program of length two, and because Taproot leaves unknown version 1 programs unencumbered, anybody can spend it with an empty witness. No key, no script to reveal, and an input small enough to be worth almost nothing.
The dust rule still bit at first. Bitcoin Core prices an output by what spending it would cost, and for this one that works out to 80 virtual bytes, which at the standard dust rate of 3 satoshis per virtual byte means it must hold at least 240 satoshis. Better than 330, still not free.
Bitcoin Core 29.0 closed the gap with ephemeral dust: a transaction may carry a single output below the dust threshold, including one worth nothing, so long as the transaction itself pays exactly zero fee. Zero fee is the trick. A parent paying nothing can never be mined on its own, so the anchor is guaranteed never to be left stranded among the live coins. It exists only inside a package alongside the child that spends it, which is where the name comes from.
Two other pieces from Bitcoin Core 28.0 make the arrangement usable. TRUC transactions, specified in BIP431 and signalled by version 3, allow one unconfirmed parent and one unconfirmed child and cap the transaction at 10,000 virtual bytes, which removes the pinning attacks that made fee bumping unreliable. Opportunistic package relay then lets a parent travel with its child as a pair, so a zero fee parent can reach a miner at all.
Where you see it
Ephemeral anchors show up in Lightning channel closes and in newer contract protocols built on presigned transactions, never in ordinary payments.
On an explorer they look wrong at first glance: an output worth nothing, spent in the very next transaction by an input with an empty witness. If you run a Lightning node, the effect is that a force close no longer needs reserved dust in every commitment, and that bumping a stuck close is far more likely to work when you need it. If you only hold bitcoin on chain you will never create one, and the benefit reaches you through Lightning being cheaper to use.
Ephemeral anchor vs dust limit
The dust limit exists to stop the set of live coins filling with outputs too small to be worth spending, and an ephemeral anchor is the single case where breaking that rule is provably safe. An ordinary dust output can sit unspent forever, costing every node on earth a little memory for a fraction of a cent. An ephemeral anchor cannot: its parent pays no fee, so no miner will take the parent unless the child spending the anchor arrives with it. The exemption is not a softening of the principle. It is a demonstration that the principle does not apply.