Can Bitcoin outputs expire on their own?

§1The Question

The question compresses three asks: (a) encumber witness-discounted outputs with a yearly deadline, (b) auto-spend on expiry without anyone broadcasting, and (c) remove the data from the chain. Of those, (a) is trivially possible today with miniscript timelocks. (b) requires the protocol to originate transactions on its own — something Bitcoin's design fundamentally rejects. (c) requires retroactively editing blocks — which the append-only chain prohibits by construction.

But there's a productive reframing. If the active goal is "shrink the UTXO set after T," and we relax "auto-spend" to mean "any party can sweep it" — the question becomes tractable. This page walks three concrete mechanisms, with a covenant template, a worked numerical example for a 10,000-sat output, and an interactive widget for the holder-vs-miner economics.

§2Three Mechanisms, Side by Side

Mechanism C is the cleanest technically and the worst politically — a consensus rule confiscating dormant UTXOs is essentially "soft-coup against Satoshi-era holders" and is unlikely to ever achieve consensus on Bitcoin. (See BIP-361's quantum sunset for the closest serious proposal and the debate it provoked.) Mechanisms A and B require opt-in per output at creation time to be remotely viable — which means they're not actually "protocol-mandated yearly resign" as the original question imagined. They're a script the user voluntarily encumbers their output with. That's a meaningful reframing.

§3Mechanism A — Anyone-Can-Spend After T

The miniscript

or_d(
  pk(owner),
  and_v(v:older(52560), 1)
)

Reads as: "spendable by owner's signature at any time, OR by anyone (no signature required) once 52,560 blocks (~1 year) have passed since this output was confirmed." The 1 in the second branch is the literal value true — the script's expiry path satisfies on its own with no witness data needed beyond the signal-no-sig push.

Compiled Tapscript

The compiler emits the following ~7-byte Tapscript leaf:

~42 bytes for the script leaf. The expiry-branch witness is just <empty> — the would-be-signature slot is empty, CHECKSIG returns 0, NOTIF enters the timelock branch, CSV passes because nSequence ≥ 52,560, and the leaf evaluates true. Anyone can construct and broadcast the spending transaction.

§4Mechanism B — Covenant-Required Burn After T

The covenant template

Using CTV (BIP-119) syntax — OP_CHECKTEMPLATEVERIFY (opcode 0xb3, currently OP_NOP4) commits the entire spending transaction template (outputs, locktime, sequences) into a 32-byte hash baked into the script:

or_d(
  pk(owner),
  and_v(
    v:older(52560),
    ctv(H_BURN)
  )
)

Where H_BURN commits to a spending transaction with exactly two outputs:

• Output 0: OP_RETURN carrying any provenance string (e.g., "EXPIRED:" || prev_outpoint), value = output_value − anchor_value − miner_fee. Unspendable; sats vanish.
• Output 1: P2A (Pay-to-Anchor) ephemeral anchor, value = 240 sats. Anyone-can-spend; the miner-of-the-spending-tx will CPFP this anchor in the same block to claim a fee.

Now the compiled Tapscript leaf adds the CTV commitment:

~76 bytes total leaf. The expiry witness is again <empty> — CTV checks the spending transaction's structure against H_BURN with no signature needed; if the spender constructed any other transaction, CTV fails and the spend is invalid.

§5Worked Numerical Example

A single specimen carried through both mechanisms. Inscription-commit scale.

If the holder maintains the output (both mechanisms)

Each year they broadcast a re-anchor tx that spends the encumbered UTXO via the key-path and creates a new identical encumbered UTXO. Cost: 300 sats/year.

The output is worth 10,000 sats. At 300 sats/year, the break-even point is 10,000 / 300 ≈ 33 years. Beyond 33 years of dormant maintenance, the holder has paid more in re-anchor fees than the output is worth. Rational holders abandon at or before year 33.

For a smaller output — say 1,000 sats — the break-even is 1,000 / 300 ≈ 3 years. Below the dust threshold the rational move at creation is "don't bother." This is the desired self-cleanup property: tiny outputs aren't worth maintaining, so they fall off the UTXO set automatically as their owners rationally decline to re-anchor.

If the holder abandons — Mechanism A

If the holder abandons — Mechanism B

Under B, the 9,520 sats are removed from circulation — every node's UTXO accounting agrees they no longer exist. The chain's economic supply contracts by that amount, which is exactly what "removed from the dataset" should mean in any rigorous sense.

§6Interactive: Deadline Economics

Adjust the parameters below to see how the maintenance burden and break-even point change for different output values and fee rates:

§7Why None of This Removes Chain Bytes

All three mechanisms shrink the UTXO set — the live spendable-state database every full node holds in RAM/disk (~5 GB). None of them shrink the historical chain — the append-only block record every archival node stores (~650+ GB and growing). When a UTXO is spent (whether by the owner, by anyone-can-spend after T, or by covenant burn), the spending transaction is a new entry on chain. The original output's bytes — including any inscription witness payload — remain in their original block forever.

If the underlying intent is "make the inscription pixels stop existing on every node forever," none of A/B/C achieve that. The only mechanism that does is per-node witness pruning, which is its own deep rabbit hole. See Appendix G of the txbook for the C++-level walk-through of why even selective witness pruning is hard with Bitcoin Core's current storage layout.

§8The Targeting Problem

The original question targeted "any transaction utilizing the witness discount." But the witness discount is universal — it applies to:

• Every Lightning channel funding output (P2WSH / P2TR)
• Every Taproot key-spend wallet (cold storage, hot wallets, exchanges)
• Every MuSig2 multisig vault
• Every SegWit v0 P2WPKH single-sig spend
• Every inscription, runestone, Counterparty payload, OP_RETURN data anchor

A protocol rule that universally encumbered witness-discounted outputs with yearly expiry would force every Bitcoin user under SegWit / Taproot to:

• Broadcast a re-anchor transaction yearly or lose their coins
• Close and reopen every Lightning channel yearly
• Bring cold-storage vaults online yearly
• Have a watchtower running for every UTXO they own

The only honest way to target inscription-style data without taking down all modern self-custody is one of:

1. Opt-in script encumbrance. Anyone creating an output writes the expiry into their own script. The protocol doesn't enforce; the script does. This is Mechanism A or B applied by user choice, output by output. Effective only for users who want their own outputs to expire.
2. Content-aware policy filtering. Discriminate at the relay layer based on what's in the witness — for example, refuse to relay transactions with an OP_FALSE OP_IF "ord" envelope. This is exactly the content filtering Bitcoin Core publicly committed not to do in its 2025-06-06 relay statement, and would in any case be trivially circumvented by direct submission to miners.
3. Tiered witness pricing. A soft fork that recomputes the weight formula so the witness discount only applies to the first N bytes per transaction, with full price above that. Discourages large payloads at the fee-market layer without expiring anyone's outputs.

§9Where This Fits in Existing Proposals

§10Open Questions

• Race dynamics at T. Mechanism A creates a permanent class of "deadline-MEV." How disruptive is it in practice? Are there block-template constructions miners would use to keep the sweep economics inside their own pool?
• Watchtower-as-a-service for re-anchoring. Who runs the cron job? Is there a sustainable business model for "for $X/year, we'll re-anchor your encumbered UTXO before deadline"? How is the watchtower's authority constrained so they can't grief?
• Interaction with Lightning. If a channel funding output were encumbered with Mechanism A or B, what happens to in-flight HTLCs near deadline? Does the channel need an explicit "renew before T" sub-protocol? (Likely yes; channel lifetimes are not currently capped.)
• Grandfathering. Any non-opt-in version (Mechanism C, or a new soft-fork rule applied to all witness-discount outputs) confiscates dormant funds. Is "applies only to outputs created after activation height" politically tractable?
• Mempool acceptance of empty-witness sweeps. Are Bitcoin Core's standardness rules permissive of a Tapscript script-path spend with no signature? (Yes for the leaf script we wrote, but worth confirming at relay-policy level.)
• Sweep transaction fee market. If millions of small UTXOs all become anyone-can-spend at the same block height, can the resulting sweep traffic itself bloat the mempool? Does a randomized expiry schedule mitigate this?

A design memo from the txbook §19 conversation. Specimens are illustrative; no protocol change has been proposed or implemented to support these scripts at the consensus layer.