Ephemeral Anchors

Ephemeral anchors are a Bitcoin relay-policy refinement that creates a clean, contention-free way to fee-bump multi-party transactions such as Lightning commitment transactions. They build on the TRUC / version-3 transaction relay rules (BIP-431) and on package relay, and require no consensus change — the innovation is entirely in what nodes agree to relay, not in what blocks may contain.

How they work

An ephemeral anchor is a tiny output — zero value in the design's pure form — whose script is anyone-can-spend (a trivially satisfiable script such as a bare OP_TRUE-style pattern). A parent transaction carries this output and can pay little or even zero fee itself; relay policy accepts it only when it arrives in a package with a child that spends the anchor and pays enough fee for both. Because the anchor is anyone-can-spend, any interested party — not just those receiving the parent's other outputs — can attach the fee-paying child. And because policy requires the anchor to be spent in the same package, it never lingers: no dust output survives into the UTXO set, which is what "ephemeral" means. The design pairs with TRUC's tight topology limits (one small unconfirmed child), so competing children conflict directly and the usual replacement rules pick a winner cleanly.

Why it improves on earlier anchors

The earlier anchor output design used on Lightning gave each counterparty its own keyed anchor and had to fund each one above the dust threshold. That meant carving real sats out of channel capacity, enlarging the commitment transaction, leaving unspent anchor dust on-chain, and — worst — creating ambiguity about whose bumping path wins, which is raw material for transaction pinning attacks. A single shared, valueless, anyone-can-spend anchor removes the pre-allocated funds, shrinks the on-chain footprint, and provides one unambiguous point where fees get added. Combined with TRUC's replacement guarantees, it lets protocol designers pre-sign transactions at zero fee and defer the entire fee decision to broadcast time — exogenous fees, decided when the mempool conditions are actually known.

Who benefits

The immediate beneficiary is the Lightning Network: commitment transactions that must confirm before a timelock expires get a reliable, unpinnable bumping path even under fee spikes. But the pattern generalizes to any pre-signed multi-party protocol — splicing, channel factories, vault designs, and shared-UTXO constructions all face the same "signed yesterday, broadcast someday, fees unknown" problem. For node runners this is another step in mempool policy becoming incentive-compatible: what your node relays converges with what miners rationally mine, which improves fee estimation and weakens censorship games. Miners simply see honestly priced packages.

D-Central documents these mempool-policy tools as part of an educational Bitcoin reference: they are unglamorous plumbing, but this plumbing is what makes second-layer bitcoin safe to hold — and a healthy fee market is, in the long run, what pays the hashrate. The design also illustrates a recurring Bitcoin pattern worth internalizing: when a problem can be solved at the policy layer with careful incentive analysis, that path is taken long before anyone reaches for a consensus change. Ephemeral anchors required no fork, no new opcode, and no coordination beyond node software upgrades — just a precise understanding of what miners rationally accept and what attackers can exploit. Years of pinning-attack research distilled into one valueless output anyone can spend: that is protocol engineering at its most economical. For the practitioner, the takeaway is simpler still — as wallet and node software adopts these rules, pre-signed transactions stop needing fee guesses baked in at signing time, and "how do I bump this?" gets a single, boring, reliable answer. Boring is exactly what money infrastructure should be.