Covenants, Exits, and Replay
Four connected threads on what covenants enable - and where they stop
FOUR THREADS
The covenant discussion split across what to deploy, which opcode, what L2 can actually do, and what happens if Bitcoin splits. Each tackles a separate layer of the same broader question: how trust-minimised does a Bitcoin-anchored layer or vault actually get?
MCCV VAULT
CTV-only vault proof-of-concept (ademan)
SIBLING-AWARE
CTV vs OP_TEMPLATEHASH (BIP-446) for BitVM, Ark, LN-Symmetry
REPLAY
Chain-split mechanics in a Core/Knots hypothetical (Kruw)
EXIT LIMITS
"Conservation of Blockspace" for L2 unilateral exit (BitcoinErrorLog)
MCCV - CTV-Only Vault
ademan, Delving Bitcoin, 2026-05-28
DESIGN
MCCV ("More Complicated CTV Vault") v0.1.0 is a vault that uses one new opcode,
OP_CHECKTEMPLATEVERIFY (CTV), and nothing else. Every state of the vault - deposit, delayed withdrawal, recovery - is a pre-signed template the user can step through; nothing's improvised at spend time. CLI tool written in Rust on BDK and rust-bitcoin; requires Bitcoin Inquisition v29.VAULT FLOW
- Deposit - hot wallet into the vault in fixed-size increments.
- Delay - withdrawals trigger a relative timelock that scales with the amount.
- Withdraw - mature outputs return to the hot wallet.
- Recovery - during the delay window the entire vault can be swept to a cold key.
- Velocity - the linear-in-amount timelock enforces a withdrawal rate ceiling.
TRADEOFFS ademan FLAGS
- Precomputation cost grows with deposit granularity - hard to do on secure hardware.
- Two-step withdrawal (mature output, then hot key, then payee) means theft risk after maturity.
- Velocity control needs single-UTXO consolidation - a real on-chain privacy hit.
- Experimental signet/regtest only.
Sibling-Aware Covenants
CTV vs OP_TEMPLATEHASH (BIP-446) for L2 designs
THE SPLIT
There are now two candidate covenant opcodes that look almost identical on paper: CTV (BIP-119) and
OP_TEMPLATEHASH (BIP-446). BIP-446 is pitched as a drop-in replacement, but with one small omission: it doesn't bind the scriptSigs of sibling inputs. That detail matters for any L2 design where a spend has to prove which other inputs were committed alongside it. BIP-446 entered Draft on 2026-02-06 and BIP-448 (Taproot-native re-bindable transactions) on 2026-03-11 - Sanders, Poinsot, Roose.WHO NEEDS WHICH
- BitVM - requires CTV's scriptSig commitment for the optimistic-verification disconnect-then-challenge flow. OP_TEMPLATEHASH cannot replicate this case.
- Ark - sibling-aware commitments matter for the exit-tree path, where each leaf needs to know which siblings exist.
- LN-Symmetry - re-bindable taproot transactions (BIP-448) are aimed directly here.
WHY IT MATTERS
Bitcoin's covenant question is no longer "CTV yes/no" - it is which sub-feature each L2 actually needs. Bundling CTV + CSFS, CTV alone, OP_TEMPLATEHASH, or LNHANCE produces materially different L2 capability sets. The bitcoindev thread maps that.
Chain-Split Replay Protection
Kruw, Delving Bitcoin, 2026-05-16
SCENARIO
The thread frames a hypothetical chain split around a BIP-110 activation: "Core" (the unrestricted side) and "Knots" (the restricted side). Without replay protection, a transaction valid on both sides spends the same UTXO twice from one user's perspective - one of the two outcomes is unwanted. The question: how do users take a deliberate position on either side?
KNOTS SIDE
Wait for post-split miners to produce blocks, then acquire a descendant of a new coinbase. Because that coinbase only exists on the Knots chain (different block ordering and structure), spending it gives the user a Knots-only history. The catch is that newly mined coins can't be spent until 100 blocks have built on top of them (Bitcoin's standard maturity rule), and Knots' difficulty adjustment may stall if its hashrate stays low.
CORE SIDE
Create a transaction that is invalid under BIP-110's new rules (e.g. contains the kind of data BIP-110 would forbid). Descendants of that output are then non-replayable on the Knots chain. A coinjoin including such an output is the simplest user-facing route.
REPLIES
garlonicon (2026-05-16): suggests verifying these recipes on regtest before any real activation, and flags that Knots' viability depends on its own difficulty mechanism behaving sensibly.
Conservation of Blockspace
BitcoinErrorLog, Delving Bitcoin, 2026-05-13
THE THESIS
"Credible Exit and The Law of Conservation of Blockspace" argues there is a hard upper bound on how many users a trust-minimised L2 can serve. Because every user must in principle be able to unilaterally exit to L1 within a bounded window, the total block-weight available in that window caps L2 user count regardless of how clever the off-chain construction is. Applies to BitVM, Ark, and Lightning exit paths.
WINDOWS DISCUSSED
1-day, 14-day, 28-day static block-weight accounting windows for unilateral L1 enforcement.
CLAIM
"Layers cannot actually scale Bitcoin" if scaling is defined as adding users while keeping exits credible.
WHAT IT MEANS PRACTICALLY
If you design an Ark round or a BitVM bridge for N users, N is bounded by available L1 blockspace in your chosen exit window. Beyond that, exits stop being credible because the L1 cannot drain the L2 fast enough during a coordinated forced-exit event. The post is a stake in the ground for the "L2 capacity bound" framing, not a final number.