I Overview
A covenant is a spending condition that restricts not just who can spend a UTXO, but how it can be spent — constraining the future transaction's outputs, inputs, or other fields. In traditional Bitcoin Script, a locking script answers one question: “prove you're authorized to spend this.” A covenant adds a second question: “prove you're spending this in the way the creator intended.”
The term comes from property law — a deed restriction that runs with the land. In Bitcoin, a covenant “runs with the UTXO.”
“Covenants are a category of proposed changes to Bitcoin's consensus rules that would allow a script to prevent an authorized spender from spending to certain other scripts.” Anthony Towns refines: “the most useful definition of covenant is that it's when the scriptPubKey of a UTXO restricts the scriptPubKey in the output(s) of a tx spending that UTXO.” — Bitcoin Optech canonical definition
Why This Matters
Without covenants, Bitcoin scripts are stateless one-shot predicates. With covenants, scripts can:
- Enforce vault withdrawal delays — funds must wait N blocks before final withdrawal, with a clawback path
- Constrain output destinations — funds can only go to pre-approved addresses
- Enable recursive structures — an output that can only be spent back to itself (perpetual covenant)
- Build Layer 2 protocols — LN-symmetry, Ark, CoinPools, timeout trees
The Fundamental Tension
The covenant debate is the deepest ideological split in Bitcoin development since the blocksize war. It touches:
- Technical risk: Do covenants introduce unacceptable complexity or attack surface?
- Philosophical risk: Should UTXOs have “memory”? Should money constrain its own future?
- Governance risk: Who decides what Bitcoin's Script can do? Bitcoin Core has effective veto power over consensus changes.
Bitcoin's scripting system is at its most contested inflection point since Taproot's activation in 2021. The central tension: Script was deliberately crippled in 2010 when Satoshi disabled 15 opcodes to prevent DoS attacks. Now, a decade and a half later, developers are debating whether to restore, extend, or fundamentally redesign that scripting layer.
II The Competing Proposals
1. OP_CHECKTEMPLATEVERIFY (CTV) — BIP-119
What it does
A single opcode that takes a 32-byte hash from the stack and verifies that the spending transaction matches that hash exactly. The hash commits to: version, locktime, scriptSigs hash, input count, sequences hash, output count, outputs hash, and the input index. It's the minimum viable covenant — a hash check.
What it enables
- Congestion control: Batched payouts via pre-committed transaction trees
- Vaults: Pre-committed delayed withdrawal path with recovery key
- Non-custodial mining pools: Committed payout distributions
- Payment channel factories
Key debates
- James O'Beirne (proponent): CTV has been under review for 5+ years. Together with CSFS it enables vaults, congestion control, non-custodial mining, DLCs, and LN-symmetry. Their limited scope makes them realistic.
- Matt Corallo (skeptic, favors TXHASH): “I have yet to see a reasoned explanation of why we should prefer CTV over TXHASH.” If TXHASH specs must be defined anyway for future upgradability, CTV is a wasted intermediate step.
- Greg Maxwell (deep skeptic): Questions whether any real-world hack has been defeated by a vault design. Notes “the lack of implementation of these tools in systems where its already easy to do so” suggests limited practical demand.
- Anthony Towns (process critic): “the ongoing lack of examples of killer apps demonstrating big wins from limited slices of new functionality leaves me completely unexcited about rushing something in the short term.”
- Erik Aronesty (minimalist): “op_ctv is quite literally not the best at anything. That's the whole point.” CTV's deliberate limitation is its strength.
“op_ctv is quite literally not the best at anything. That's the whole point.” — Erik Aronesty (mailing list)
2. OP_CHECKSIGFROMSTACK (CSFS) — BIP-348
What it does
Verifies a BIP-340 Schnorr signature against an arbitrary message (not the transaction hash). Standard OP_CHECKSIG only verifies signatures against the transaction's sighash. CSFS removes that restriction. Takes three parameters: signature, message, and public key.
What it enables (especially combined with CTV)
- LN-Symmetry (Eltoo): Simplified payment channels where the latest state always wins
- Oracle attestations: Scripts can verify signatures from external data sources
- Delegation: Sign over spending authority to another key
- DLC optimizations: Simpler Discreet Log Contract implementations
- Transaction introspection: With OP_CAT for message construction
The Covenants Support Wiki compiled by /dev/fd0 (December 2024) found CSFS has “unanimous support” and appears in multiple proposal bundles.
3. CTV + CSFS Together
“if nobody in Core wants to engage at all with consensus changes, then the result is effectively the same as a veto.” — Andrew Poelstra (signed despite technical reservations: “technically good enough”)
Antoine Poinsot & Greg Sanders (“Making the case for CTV+CSFS”): Argued CTV+CSFS represents “the valid Schelling point” — specific use cases (LN-symmetry, Ark, DLCs, BitVM) are well-understood and proven. “The onus is on the proposer to overcome objections.”
The recursive covenant revelation
Anthony Towns demonstrated that CTV+CSFS trivially enables recursive covenants — the very thing BIP-119's motivation section claims to avoid. The construction: create a throwaway key pair, build a tapscript combining CSFS and CTV, derive the scriptPubKey, calculate the CTV hash for a payment back to itself, sign with the throwaway key, then destroy the private key. Funds sent to this address can only ever be spent back to themselves — a perpetual self-spending covenant. Working demo on mutinynet.
Olaoluwa Osuntokun (pushback): “The example that you've come up with to 'directly undermine' the claimed motivations of BIP 119 is still fully enumerated (the sole state is declared up front), and doesn't contain dynamic state.”
4. SIGHASH_ANYPREVOUT (APO) — BIP-118
A new sighash flag that allows signatures to not commit to the input being spent. The same signature can authorize spending from different UTXOs — enabling rebindable transactions.
What it enables
- LN-Symmetry (Eltoo): The original motivation; each new channel state replaces any previous with the same signature
- Drivechains (with trusted setup)
- Covenants (indirectly, combined with other opcodes)
Why it stalled: Designed for a specific use case (LN-symmetry). Developers increasingly prefer CTV+CSFS as a more general primitive. The Covenants Wiki noted APO “lacks developer interest; alternatives exist for achieving similar functionality.”
5. OP_TXHASH — The Generalized Alternative
Computes a hash of selected transaction fields based on a flags argument. Where CTV commits to the entire template, TXHASH lets the script select which fields to commit to.
Brandon Black's minimal TXHASH+CSFS: Three new opcodes that subsume both CTV and APO. OP_TXHASH with 5 hash modes (mode 0 = CTV, modes 1-4 = APO variants), plus OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY.
“By splitting the hashing from the validation of BIP-119, the hash can be used in ways other than OP_EQUALVERIFY.” — Brandon Black
The key debate: Matt Corallo argues that if TXHASH specs must be defined anyway for future upgradability, CTV is a wasted intermediate step: “Preferring to do something worse because something better would require someone reasonable pick some reasonable encoding is not a good way of engineering.”
The Covenants Wiki found TXHASH is “more expressive” but generates “meaningless” template combinations.
6. OP_TX — Generalized Introspection
Pushes raw transaction fields onto the stack (version, locktime, input/output counts, amounts, scripts, witness data). Unlike TXHASH which produces a hash, OP_TX gives the script direct access to transaction data.
Why it's more powerful: With OP_TX, a script can examine and compare individual fields — not just verify a hash match. Conditions like “output 0 must send at least X satoshis to address Y” without committing to the entire transaction structure. Russell showed CTV is “approximated by” a specific combination of nine OP_TX flags — making CTV a trivial special case.
7. OP_VAULT — Purpose-Built Vault Covenant
Two purpose-built opcodes (OP_VAULT and OP_VAULT_RECOVER) specifically for vault workflows. O'Beirne: “a design solely concerned with making the best vault use possible, with covenant functionality as a secondary consideration.”
Towns' critique
- Recovery address exposure is dangerous: “as soon as your recovery address is revealed, anyone can move all your funds into cold storage”
- No withdrawal caps — can't limit amounts
- UTXO locking inefficiency
“if you can secure the rescue/abort key you could use the process for the primary” — Greg Maxwell (challenging vaults generally)
8. OP_CAT — The Simplest Primitive
Concatenates the top two stack elements. That's it. Disabled by Satoshi in 2010 because repeated OP_DUP + OP_CAT could create exponentially large elements (1 byte to 1TB in 40 iterations). Tapscript's 520-byte element limit eliminates this vulnerability. Proposed as opcode 126 (OP_SUCCESS126) in tapscript.
What it enables
- Tree signatures: ~1,000 keys in <1KB (logarithmic)
- Post-quantum Lamport/Winternitz signatures: Quantum-resistant using only hash + concatenation
- Merkle proof verification on stack
- Covenant emulation: Combined with OP_CHECKSIGFROMSTACK, enables transaction introspection
- Non-equivocation contracts: Punish double-signing in payment channels
- MATT generality: “With this new opcode, the full generality of MATT (including the fraud proofs) can be obtained with just two opcodes: OP_CHECKCONTRACTVERIFY and OP_CAT.” — Salvatore Ingala
Why it's controversial: OP_CAT's power comes from composition. Alone it's trivial. Combined with existing opcodes, it creates emergent capabilities — including things some developers don't want (inscriptions, AMMs, state-carrying covenants). LNHANCE explicitly excluded OP_CAT for this reason.
Winternitz signatures (with OP_CAT)
conduition demonstrated that WOTS can be implemented in Bitcoin Script with OP_CAT, providing post-quantum security. Winternitz = 7,948 bytes total vs. Lamport = ~10,721 bytes — a 26% reduction.
Lamport signatures (no changes needed)
Ethan Heilman showed Lamport signatures can be verified in Bitcoin Script TODAY by exploiting ECDSA signature length variability (the “ECDSA nonce trick”). Achieves 284 security but: “Do not use this signature scheme in a Bitcoin output unless your intent is for that output to be a fun crypto bounty.”
9. MATT / OP_CHECKCONTRACTVERIFY (CCV)
A single opcode that takes 5 stack parameters (data, index, pk, taptree, flags) and checks whether a specified input or output's scriptPubKey matches a P2TR address derived from those parameters. This lets scripts verify that outputs conform to expected contract states.
Combined with OP_CAT, achieves “full generality of MATT” — Merklize All The Things — including fraud proofs for arbitrary computation.
Limitation: Amount introspection is limited — input amounts toward the same output are summed as a lower bound. Johan Toras Halseth found this “insufficient at least for the use cases I had in mind” for CoinPool (which requires splitting/combining output amounts).
10. Rusty Russell's 4-BIP Script Restoration Quartet
The maximalist proposal — restore Bitcoin's scripting language to its original power:
- BIP [1/4] — Varops Budget: The safety net. Extends the sigops budget into a variable-operations budget using benchmarks. This makes everything else safe.
- BIP [2/4] — Tapscript v2 (tapleaf 0xc2): Re-enables 15 disabled opcodes:
- Splice: OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT
- Bitwise: OP_INVERT, OP_AND, OP_OR, OP_XOR
- Bitshift: OP_UPSHIFT, OP_DOWNSHIFT
- Arithmetic: OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD
- BIP [3/4] — OP_TX: Transaction introspection. The covenant primitive.
- BIP [4/4] — New Opcodes: OP_CHECKSIGFROMSTACK, OP_SEGMENT, OP_BYTEREV, OP_ECPOINTADD, OP_INTERNALKEY, OP_MULTI.
“These restrictions removed much of the ability for users to control spending conditions, frustrating the ideal of programmable money without third-party trust.” — Rusty Russell
“Once the safety net of the varops budget is in place, disabled opcodes can be re-enabled, stack object size and total capacity extended.” — Rusty Russell
11. LNHANCE — The Conservative Bundle
Bundles four opcodes: CTV + CSFS + OP_INTERNALKEY + OP_PAIRCOMMIT. Specifically designed to improve Lightning and L2 scaling while avoiding general covenant capabilities.
Explicitly excluded OP_CAT because it “enables introspection, including parent transaction introspection, state carrying and script intractable exogenous asset protocols.” LNHANCE wants better Lightning without enabling inscriptions, AMMs, or MEV.
12. Graftleaf — Program Composition and Delegation
A new Taproot leaf version (0xc2) enabling:
- Program composition: Multiple witness programs execute sequentially on a single leaf
- Generic delegation: Users commit to additional spending conditions at signature-time via the annex
- Vault-of-vaults: Compose multiple personal vaults into higher-level multisig structures
Core execution logic: fewer than 60 lines of code. Works within existing P2TR addresses. “Delegation from any valid spending path to arbitrarily complex compositions.”
13. ColliderScript — Covenants Without Soft Forks
Achieves covenants using 160-bit hash collisions (SHA-1 + RIPEMD-160) within existing Bitcoin Script. Requires ~286 hash operations to spend — equivalent to the entire Bitcoin network's output over ~33 hours. Transactions near the 4MB limit.
“Not a replacement for a covenant opcode” but proves covenants are theoretically achievable today. Demonstrates that Bitcoin's Script already contains latent capabilities.
14. Slashing Covenants — Covenants via Economic Incentives
Instead of cryptographic enforcement, slashing covenants use economic penalties — if you violate the covenant, your funds are burned. Works by requiring two parallel signatures (ECDSA + Lamport) that must match; a mismatch makes a “slashing output” spendable by anyone.
Works today, no new opcodes needed. “Less secure than a covenant enforced by an opcode” but parallels how “bitcoin mining itself is secure only through cryptoeconomic incentives.”
III What Covenants Enable
Vaults
The most cited covenant use case. A vault enforces: (1) withdrawals require a time delay, (2) during the delay, a recovery key can clawback to cold storage, (3) after the delay, funds release normally.
Multiple design approaches exist: pre-signed transactions (key deletion), CTV-based, OP_VAULT/OP_UNVAULT (withdrawn), MATT-based, OP_CAT-based.
“if you can secure the rescue/abort key you could use the process for the primary” — Greg Maxwell (the fundamental challenge to vaults)
Vault advocates respond that the recovery key can be less accessible (geographically distributed, multi-party) because it's only needed in emergencies.
LN-Symmetry (Eltoo)
Requires CTV+CSFS or APO. Replaces Lightning's current penalty-based channel mechanism with a simpler “latest state wins” approach. No more toxic waste problem. Enables multiparty channels (3+ participants). Minimal storage requirements (few kilobytes) — ideal for hardware wallets.
Current Lightning (penalty-based): If Alice broadcasts an old state, Bob can take all the funds as punishment. Requires watching the chain constantly and storing every old state.
LN-Symmetry: Any party can publish any state, and a newer state can always replace an older one. No punishment needed — just correction. Safer backup restoration. Multiparty variant with optional penalties proposed (Jan 2025).
Ark Protocol
A second-layer protocol (Burak Keceli, May 2023) where users hold off-chain “virtual UTXOs” (vTXOs) that expire after ~4 weeks. An Ark Service Provider (ASP) creates rapid blinded coinjoin sessions every ~5 seconds. Recipients receive payments without inbound liquidity (unlike Lightning). On-chain footprint is “orders of magnitude less” than Lightning. Privacy via blinded mixing and standardized denomination sets.
Covenant requirement: Full non-interactive Ark needs CTV or APO. Without covenants, recipients must be online to co-sign n-of-n multisig. The covenant-less variant (clArk) has significant limitations.
Current status: Bark implementation on mainnet (Oct 2024). Arkade launched (Nov 2025). Ark Wallet SDK released (Feb 2025). hArk (hash-lock variant) released (Feb 2026). V-PACK standard for stateless VTXO verification (Mar 2026).
BitcoinTalk perspective (BlackHatCoiner): Self-custody caveat — users retain control “as long as they interact with their ASP at least once every few days.” MarryWithBTC raised skepticism about VTXO expiry creating fund seizure risk.
Congestion Control / Timeout Trees
CTV enables a single on-chain transaction to commit to a tree of N future payouts. The exchange or service posts one transaction; users settle when they choose. Reduces block space by orders of magnitude during high-fee periods.
Timeout trees: offchain transaction trees that only remain safe against counterparty theft for a limited period. Superscalar (timeout tree channel factories) proposed Nov 2024.
CoinPools / Joinpools
Shared UTXO ownership where multiple users share a single on-chain output with privacy (spending member not identifiable on-chain). Each can exit unilaterally. Requires covenant introspection (OP_CHECKCONTRACTVERIFY or OP_TX) to verify exit transactions. MATT + OP_CAT can manage joinpool state transitions. CTV-based payment pool proof-of-concept (Jan 2025).
DLCs & BitVM
CTV+CSFS enables significant DLC optimizations: oracle attestation verification, reduced on-chain footprint, simpler implementation. BitVM fraud proofs benefit from CSFS (verify signatures against arbitrary messages). Glock (garbled locks) achieves 550x improvement over BitVM2 using Schnorr signatures as fraud proofs.
IV The OP_RETURN War
Not technically covenants, but the OP_RETURN debate is inseparable from the covenant debate because both concern what Bitcoin's Script should be for.
The Status Quo
Bitcoin Core limits OP_RETURN outputs to 83 bytes and one per transaction. These are standardness rules (relay policy), not consensus rules.
Antoine Poinsot's Proposal (April 2025)
Mailing list thread (~70 messages): Relax or remove the limits. The restrictions have failed — developers store data in unspendable Taproot outputs instead, which is worse because those bloat the UTXO set permanently (OP_RETURN outputs are prunable). The Citrea Clementine bridge stores data in unspendable Taproot outputs specifically because OP_RETURN limits are too small.
The Mailing List Positions
“million-dollar (or more) business incentives” cannot be thwarted by relay policy. If restrictions push users to private transaction rails, “I feel we'd be giving up on one of the most valuable properties the network has” — permissionless access. “There is no need to discriminate” when blocks are consistently full. — Pieter Wuille (reversed his own earlier position)
“standardness limits aren't holy, they're a hack... sometimes a very useful hack. They should only exist when their benefits well outweigh their costs.” Since 2014, minimum feerate buying power increased 171x, blocks are consistently full, and compact block relay means the old propagation argument is inverted. — Greg Maxwell
“This idea is utter insanity. The bugs should be fixed, not the abuse embraced.” — Luke Dashjr (strong opponent, advocates returning to script whitelisting)
Peter Todd: Supports full removal of both size and count limits. Multiple OP_RETURN outputs serve legitimate purposes like SIGHASH_SINGLE signing.
Anthony Towns: Encoding data undetectably is “a standard exercise.” Filtering is a perpetual losing game. “Acting tough about it at best has zero effect, and at worst generates publicity for the spammers.”
BitcoinTalk Forum Perspective
Thread (341+ replies): The forum surfaced the cultural dimension that the mailing list largely avoided.
The 80-byte limit is actively harmful because it pushes data embedders toward worse methods. OP_RETURN data is “completely prunable and pruned.” “Having some developer going around playing wack-a-mole blocking stuff that isn't perfectly imitating ordinary transactions is a huge liability.” “If you don't want to store that prunable data, simply don't.” — gmaxwell (on BitcoinTalk)
d5000: Removing limits is actually anti-centralization: “restrictive standardness settings” create “strong centralization effect” by giving large pools additional income from non-standard transaction fees that small miners can't access.
pooya87 (skeptic): Historical evidence shows limits work — most spam respects the 80-byte boundary. Analogy: “Like going to emergency room for appendicitis but they remove your kidney instead.”
takuma sato (purist): “The point of Bitcoin is to move money from A to B, everything else is bloat.”
“Bitcoin is Money” Counterproposals
Reduced Data Temporary Softfork (~30 messages): A temporary softfork (expiring after one year) to restrict arbitrary data storage at consensus level, “strongly re-affirming in consensus that bitcoin is money, not data storage.”
Soft Fork Compromise on OP_RETURN (~12 messages): Majorian proposed making the existing 83-byte limit into a consensus rule: “By enforcing this at consensus, we simply make permanent the relay standards that nodes have followed in practice for much of Bitcoin's history.”
BitcoinTalk: BIP 110 (59+ replies): The forum unanimously rejected BIP 110. Peter Todd demonstrated its futility by embedding BIP-110's full text into a compliant transaction. Jameson Lopp: “Why would anyone voluntarily take a pay cut?” and “kicks off a never-ending game of cat and mouse.” pooya87 called it “an attack on Bitcoin and its principles.” gmaxwell pointed out that presigned transactions could be rendered unspendable retroactively.
d5000's “Three Doors” Analysis (Bitcoin Core 30)
BitcoinTalk (51 merits, 20+ replies): Three methods of on-chain data storage, ranked by harm:
- Door 1 (fake public keys): Most harmful, creates permanent UTXOs
- Door 2 (Taproot witness): Second most harmful
- Door 3 (OP_RETURN): Least harmful, prunable
Opening Door 3 wider encourages spammers toward the least destructive method. The change doesn't make NFTs cheaper since alternative methods remain competitive on fees.
V The Great Consensus Cleanup
The one thing nearly everyone agrees on. Four bug fixes through a soft fork:
- Timewarp attack: Miners can manipulate difficulty by exploiting timestamp validation across difficulty periods. Fix: 7200-second grace period + invalidate negative-duration difficulty periods (Murch-Zawy attack).
- Worst-case block validation time: Legacy transactions can be crafted to take minutes to validate. Fix: per-transaction sigops limit for legacy scripts.
- Merkle tree weakness: 64-byte transactions create ambiguity between internal Merkle nodes and transaction data. Fix: make 64-byte transactions consensus-invalid (BIP53, merged May 2025).
- Duplicate coinbase transactions: BIP-34 doesn't fully prevent duplicate coinbase txids after block 1,983,702. Fix: mandate nLockTime = block height - 1.
Status: BIP54 merged May 2025. Bitcoin Core #32521 and #32155 implementing changes. Bitcoin Inquisition added BIP54 implementation (Feb 2026). Test vectors published (Nov 2025). Active implementation phase.
Demonstrates that Bitcoin can evolve through consensus when changes are clearly beneficial and don't expand the protocol's scope.
VI The Covenants Landscape
The Covenants Support Wiki
/dev/fd0 compiled a Bitcoin Wiki page (December 2024) where developers evaluated proposals. Key findings:
- CSFS has “unanimous support” and appears in multiple proposals
- OP_CAT enables introspection but is criticized for inefficiency alone
- CTV is “limited in scope” — some prefer gradual upgrades
- TXHASH is “more expressive” but generates “meaningless” template combinations
- APO “lacks developer interest” — alternatives exist
- OP_VAULT is “specialized” with limited demand
Power/Simplicity Spectrum
The Three Philosophical Camps
1. Minimalists CTV / LNHANCE
Add the least possible. CTV's weakness is its strength. Ship something small, iterate later. “The onus is on the proposer to overcome objections.” LNHANCE explicitly excludes OP_CAT to avoid enabling inscriptions, AMMs, or MEV.
“The onus is on the proposer to overcome objections.” — Antoine Poinsot
2. Generalists TXHASH+CSFS / OP_CAT
If you're going to change consensus, don't waste the opportunity on something too narrow. Build primitives, not features. “By splitting the hashing from the validation, the hash can be used in ways other than OP_EQUALVERIFY.”
3. Restorationists Russell's Quartet
Bitcoin's Script was crippled unnecessarily. Restore it properly with safety constraints. The varops budget makes everything safe. Don't do this piecemeal. “These restrictions removed much of the ability for users to control spending conditions.”
VII Agreed / Contested / Unresolved
Agreed
- Bitcoin's Script is too limited. Even skeptics like Greg Maxwell don't argue Script is perfect — they disagree about whether proposed changes address real problems.
- OP_RETURN standardness limits have failed. Near-consensus (Luke Dashjr as the notable exception) that 83-byte limits are easily circumvented and push data storage toward worse alternatives.
- The Great Consensus Cleanup should happen. Broad support. BIP54 merged. Active implementation.
- Taproot's versioning system works. All proposals use Taproot's leaf versioning or OP_SUCCESSx mechanism for safe deployment, validating Taproot's design as an upgrade platform.
- CSFS is broadly supported. Appears in nearly every proposal bundle. The Covenants Wiki found “unanimous support.”
Deeply Contested
- CTV vs. TXHASH vs. OP_TX. Three competing approaches to transaction commitment/introspection with different power/risk tradeoffs. CTV is the narrowest (hash of the whole transaction), TXHASH allows selecting specific fields, OP_TX pushes raw fields onto the stack.
- Whether covenants are needed at all. Maxwell: presigned transactions replicate most functionality. Towns: no demonstrated killer apps. Proponents: LN-symmetry, Ark, vaults are proven use cases.
- Piecemeal vs. comprehensive. CTV+CSFS now vs. Russell's quartet vs. clean-sheet redesign (Simplicity/bll).
- The governance question. Bitcoin Core has effective veto power. The open letter was controversial — is it advocacy or pressure? Poelstra: “if nobody in Core wants to engage at all with consensus changes, then the result is effectively the same as a veto.”
- OP_CAT's emergent risks. Does re-enabling concatenation open Pandora's box? LNHANCE's explicit exclusion reflects real concern.
Unresolved
- Activation mechanism. No consensus on BIP-8, BIP-9, flag day, etc. The 2017 SegWit activation trauma looms. No new activation has occurred since Taproot (2021). See Optech: Soft Fork Activation.
- The philosophical question. Should UTXOs constrain their own future spending? Both sides have technically valid arguments.
- Data storage on chain. Is Bitcoin purely money, or a general-purpose commitment layer? The answer determines whether Ordinals, Runes, and Inscriptions are features or attacks. BitcoinTalk debates this explicitly; the mailing list treats it as settled.
- Post-quantum preparedness. Script-based quantum resistance is possible (Lamport/Winternitz) but impractical at current sizes. Whether to optimize for this threat is open. BitcoinTalk's debate on Lopp's BIP.
- Timeline. Despite 5+ years of CTV review, no activation date exists for any proposal as of early 2026.
- Accidental confiscation risk. Soft forks that restrict previously valid behavior can make existing funds unspendable — only reversible via hard fork. See Optech: Accidental Confiscation.
VIII Key Voices
Developers & Researchers
| Developer | Position | Notable Quote |
|---|---|---|
| James O'Beirne | CTV champion, OP_VAULT author | “vaults are an almost necessary part of bitcoin's viability” |
| Matt Corallo | Prefers TXHASH over CTV | “I have yet to see a reasoned explanation of why we should prefer CTV over TXHASH” |
| Greg Maxwell | Deep skeptic of covenants generally | “if you can secure the rescue/abort key you could use the process for the primary” |
| Andrew Poelstra | Pragmatic CTV+CSFS supporter | “if nobody in Core wants to engage at all with consensus changes, the result is effectively the same as a veto” |
| Anthony Towns | Process critic, prefers clean-sheet (bllsh/Simplicity) | “the ongoing lack of examples of killer apps...leaves me completely unexcited” |
| Rusty Russell | Script Restoration maximalist | “These restrictions removed much of the ability for users to control spending conditions” |
| Ethan Heilman | OP_CAT champion, ColliderScript, slashing covenants | Demonstrated Lamport sigs work today, ColliderScript covenants without forks |
| Antoine Poinsot | CTV+CSFS as “Schelling point,” OP_RETURN relaxation | “the onus is on the proposer to overcome objections” |
| Salvatore Ingala | MATT/CCV architect | “the full generality of MATT including fraud proofs with just two opcodes” |
| moonsettler | LNHANCE (conservative bundle) | Excluded OP_CAT to avoid “state carrying and script intractable exogenous asset protocols” |
| Erik Aronesty | CTV minimalist | “op_ctv is quite literally not the best at anything. That's the whole point” |
| Luke Dashjr | Opposes all data storage relaxation | “This idea is utter insanity” |
| Pieter Wuille | Reversed position on OP_RETURN | “There is no need to discriminate” when blocks are full |
| Burak Keceli | Ark protocol author | Ark needs covenants for full non-interactive operation |
| Josh Doman | Graftleaf (composition + delegation) | “Delegation from any valid spending path to arbitrarily complex compositions” |
| Brandon Black | TXHASH+CSFS as CTV+APO unifier | “By splitting the hashing from the validation, the hash can be used in ways other than OP_EQUALVERIFY” |
| Antoine Riard | Technical refinement of CTV | CTV should be restricted to witness v1 to reduce attack surface |
| Olaoluwa Osuntokun | Defends BIP-119 motivations | Recursive covenant example is “still fully enumerated...doesn't contain dynamic state” |
| conduition | Winternitz signatures with OP_CAT | Demonstrated 26% size reduction over Lamport for post-quantum sigs |
BitcoinTalk Voices
| Forum Member | Role | Notable Quote |
|---|---|---|
| d5000 | Decentralization maximalist, empirical analyst | “Lifting the limits would thus be an anti-centralization measure” |
| pooya87 | Skeptic of developer authority | “Like going to emergency room for appendicitis but they remove your kidney instead” |
| Satofan44 | Immutability / property rights defender | “How we approach this lack of consensus will have a bigger impact on Bitcoin's future than any amount of 'stolen coins'” |
| BlackHatCoiner | Bridges technical and philosophical | “Bitcoin has clearly charted another course...become the cornerstone of honest and true money” |
| gmaxwell (on forum) | Authoritative technical voice | “standardness limits aren't holy, they're a hack” |
IX Dependency Graph: What Enables What
X Timeline
XI Alternative Scripting Languages
Two clean-sheet alternatives to extending Bitcoin Script:
Simplicity
Nine primitive operators (“combinators”) with formally specified semantics. Jets provide performance-equivalent implementations of common functions. Could implement SIGHASH_ANYPREVOUT and other features without separate soft forks. SimplicityHL (compile Rust-like programs to Simplicity) released Aug 2025. Currently on Elements/Liquid test branches. No soft fork proposal for Bitcoin.
Basic Bitcoin Lisp Language (bll)
Conceptually based on Chia Lisp. Includes symbll (compiler) and bllsh (REPL). Can implement quantum-safe signatures. Proposed Nov 2024. No BIP submitted.
Anthony Towns advocates for these clean-sheet approaches over piecemeal opcode additions.
XII The Mathematics of Covenants
Every covenant proposal rests on a small set of mathematical primitives. This section covers all of them, from the ground up. If you understand these, you can read any covenant BIP.
A. Finite Fields and Modular Arithmetic
All Bitcoin cryptography operates in finite fields — sets of integers where arithmetic wraps around at a prime number p.
Bitcoin uses two primes:
- The field prime (coordinates): p = 2256 − 232 − 977
- The group order (scalars): n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
Key operations:
a · b mod p — multiplication wraps at p
a−1 mod p — the unique value where a · a−1 ≡ 1 (mod p) Modular arithmetic in Fp
The modular inverse exists for every nonzero element because p is prime. Computed via Fermat's little theorem: a−1 ≡ ap−2 (mod p).
B. Elliptic Curves and secp256k1
Points on this curve form a group under an operation called point addition:
λ = (y2 − y1) · (x2 − x1)−1 mod p
x3 = λ2 − x1 − x2 mod p
y3 = λ(x1 − x3) − y1 mod p Point addition (P ≠ Q)
λ = (3x12) · (2y1)−1 mod p Point doubling (tangent line slope) — the +7 term vanishes because its derivative is 0
Scalar multiplication: d · G means adding G to itself d times. This is a one-way function: given d and G, computing P = d · G is fast (double-and-add, O(256) steps). Given P and G, recovering d is the Elliptic Curve Discrete Logarithm Problem (ECDLP) — believed to require ~2128 operations classically.
x = 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
y = 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
Every public key is P = d · G for some secret scalar d (the private key).
C. Hash Functions
Hash functions are the workhorses of covenants. Every proposal uses them differently.
The tag prefix ensures that hashes in different contexts can never collide. Tags used in Taproot:
•
"TapLeaf" — hashing a tapscript leaf•
"TapBranch" — combining two branches in the Merkle tree•
"TapTweak" — tweaking the internal key•
"BIP0340/challenge" — Schnorr signature challenge
Properties that matter for covenants
- Preimage resistance: Given H(x), finding x requires ~2256 work. This is why CTV's hash commitment is binding.
- Collision resistance: Finding any x ≠ y where H(x) = H(y) requires ~2128 work (birthday bound). ColliderScript exploits the weaker 280 birthday bound of RIPEMD-160.
- Determinism: Same input always produces same output. This is what makes CTV work — only one transaction can match the committed hash.
D. Schnorr Signatures (BIP-340)
Taproot uses Schnorr signatures instead of ECDSA. All covenant proposals that interact with Tapscript use Schnorr verification. CSFS extends it to arbitrary messages.
Key generation
Public key: P = d · G BIP-340 uses x-only public keys (just the x-coordinate, 32 bytes)
Signing
Compute challenge: e = Htag(Rx || Px || m)
Compute: s = k + e · d mod n
Signature: (Rx, s) — 64 bytes total Schnorr signing
Verification
Check: s · G = R + e · P Verification equation — this is what OP_CHECKSIG computes
OP_CHECKSIGFROMSTACK (CSFS) removes this restriction. It lets the script specify m as any value from the stack. This is what enables oracle attestations, delegation, and — combined with CTV — covenants.
Why Schnorr (not ECDSA) for Taproot
- Linearity: Schnorr signatures are linear — (s1 + s2) · G = s1 · G + s2 · G. This enables key aggregation (MuSig), signature aggregation (DahLIAS), and adaptor signatures. ECDSA lacks this property.
- Provable security: Schnorr has a security proof in the random oracle model. ECDSA does not.
- Simpler: No DER encoding, no s-value malleability, fixed 64-byte size.
E. Taproot Mathematics
Taproot is the foundation all covenant proposals build on. Understanding the key tweak and Merkle tree is essential.
The Key Tweak
A Taproot output commits to an internal key P and an optional script tree c. The output key Q is:
The tweak t = HTapTweak(Px || r) is a scalar. The output key is a point. Anyone who knows P and r can verify the tweak, but the output key Q looks like any other public key on the curve.
Key-path spend
If you know the private key d for P, you can spend with private key d + t (mod n). This produces a standard Schnorr signature — indistinguishable from any other spend.
Script-path spend (MAST)
The script tree is a Merkle tree of TapLeaf hashes:
Branch hash: HTapBranch(min(hL, hR) || max(hL, hR))
Root: r = the top-level branch hash v is the leaf version byte (0xc0 for current tapscript)
To spend via script path, you reveal: the script, a Merkle proof (sibling hashes), and the internal key P. The verifier recomputes Q and checks it matches the output.
0xc0. Covenant proposals use new leaf versions to activate new opcodes safely:• Russell's Script Restoration and Graftleaf both propose
0xc2• OP_SUCCESSx opcodes in current
0xc0 leaves make the script succeed unconditionally — this is the upgrade hook for CTV, CSFS, OP_CAT
NUMS points (Nothing Up My Sleeve)
Some covenant constructions (Winternitz signatures, key-path-disabled covenants) need an internal key P where nobody knows the private key. A NUMS point is generated by hashing a known string and mapping to a curve point:
F. The CTV Template Hash
CTV (BIP-119) commits to a template hash of the spending transaction. Understanding exactly what's hashed is essential for understanding what CTV constrains and what it leaves free.
SHA-256d(
nVersion
|| nLockTime
|| SHA-256d(scriptSigs)
|| input_count
|| SHA-256d(sequences)
|| output_count
|| SHA-256d(outputs)
|| input_index
) BIP-119 template hash — the spending transaction must match this exactly
What's committed: All outputs (amounts + scriptPubKeys), all sequences, version, locktime, input count, input index.
What's NOT committed: The input outpoints (which UTXOs are being spent) and their values. This is deliberate — it means the same CTV template can be satisfied by spending different UTXOs, enabling batched payouts.
Why this is a covenant
The locking script is: <hash> OP_CHECKTEMPLATEVERIFY. When you try to spend, the node computes the template hash of your transaction and checks: does it equal <hash>? If not, the spend fails. The output has constrained its own future.
G. Post-Quantum Signature Primitives
Several covenant-adjacent proposals use hash-based signature schemes that resist quantum computers.
Lamport Signatures
- Key generation: Generate 512 random 256-bit values: sk[0][0], sk[0][1], sk[1][0], sk[1][1], …, sk[255][0], sk[255][1]
- Public key: Hash each one: pk[i][b] = H(sk[i][b])
- Signing: For each bit i of the message, reveal sk[i][mi]
- Verification: Hash each revealed value and check it matches the public key
Size: Public key = 512 × 32 = 16,384 bytes. Signature = 256 × 32 = 8,192 bytes. Total: ~24 KB per signature. One-time use only — signing two messages reveals enough secret keys to forge.
Security: Relies only on hash preimage resistance. No algebraic structure for quantum computers to exploit.
Winternitz One-Time Signatures (WOTS)
Winternitz compresses Lamport signatures by using hash chains instead of individual hashes:
Break the 256-bit hash into 64 four-bit words
For each word i: chaini = H(15)(ski)
Public key: {H(15)(sk0), …, H(15)(sk63)}
Signature for word value v: H(v)(ski) H(k) means applying H iteratively k times
Size with OP_CAT (conduition's scheme): 7,948 bytes total (5,610 script + 2,240 witness) — a 26% reduction vs. Lamport.
The ECDSA nonce trick (Heilman)
Lamport signatures can be verified in today's Bitcoin Script by exploiting ECDSA signature length variability. Set the nonce k = 2−1 mod n (the modular inverse of 2), producing an exceptionally short r-value. A known k leaks the private key — but the Lamport layer provides the real security. OP_SIZE measures signature length; different lengths encode different bit values.
H. Hash Collision Mathematics (ColliderScript)
ColliderScript achieves covenants without new opcodes by exploiting the birthday paradox applied to 160-bit hashes.
• SHA-256 (256-bit): collision at ~2128 — infeasible
• RIPEMD-160 (160-bit): collision at ~280 — expensive but achievable
• SHA-1 (160-bit): collision at ~280 — same
ColliderScript uses a dual-evaluation trick: the same data is processed two ways simultaneously:
"Small Script": SHA-1 and RIPEMD-160 reimplemented using 32-bit OP_ADD/OP_SUB
Find values A, B where:
OP_SHA1(A) = BigScript_dGen(w, t)
SHA1(B) = SmallScript_dGen(w, t)
If both match → A = B (with overwhelming probability) Cost: ~286 hash operations ≈ 33 hours of the entire Bitcoin network
I. Merkle Trees (Beyond Taproot)
Merkle trees appear in three distinct contexts in the covenant landscape:
1. Taproot script trees (MAST)
Binary tree of TapLeaf and TapBranch hashes. Reveals only the executed script path + Merkle proof. Covered in Section E above.
2. CTV commitment trees
CTV enables transaction trees — a single on-chain transaction commits to a binary tree of future transactions. Each leaf is a payout; internal nodes are intermediate transactions. The tree is pre-computed; users claim their leaf when ready.
Level 1: 2 txs → 4 outputs
Level 2: 4 txs → 8 outputs
…
Level k: 2k leaf payouts
On-chain cost: O(log N) per claim instead of O(N) for all payouts Congestion control: batch N payouts with one on-chain transaction
3. MATT fraud proofs
Ingala's OP_CHECKCONTRACTVERIFY uses Merkle trees to represent computation states. Each leaf is a step in a computation; the Merkle root commits to the entire execution trace. A fraud proof reveals a single step where the claimed computation diverges from the correct one.
J. Sighash Flags and Transaction Binding
Understanding sighash flags is essential for APO and TXHASH proposals. A sighash flag determines which parts of the transaction the signature commits to.
| Flag | Value | Commits to |
|---|---|---|
| SIGHASH_ALL | 0x01 | All inputs and all outputs |
| SIGHASH_NONE | 0x02 | All inputs, no outputs |
| SIGHASH_SINGLE | 0x03 | All inputs, only the output at the same index |
| ANYONECANPAY | * | 0x80 | * | Only the current input (not all inputs) |
SIGHASH_ANYPREVOUT (BIP-118)
Adds a new dimension: the signature does not commit to the input outpoint (which UTXO is being spent). The same signature can authorize spending from any UTXO with the same scriptPubKey. This is what enables LN-symmetry — a new state transaction can replace any previous one.
TXHASH modes
Brandon Black's proposal generalizes sighash flags into 5 hash modes for OP_TXHASH:
- Mode 0: CTV-equivalent (all outputs, version, locktime, sequences)
- Modes 1-4: APO variants (different combinations of input/output commitment)
Future modes use OP_SUCCESS semantics — they succeed unconditionally today, allowing safe extension later.
K. Putting It All Together: How a Covenant Executes
Here is the complete mathematical flow for a CTV+CSFS recursive covenant (Towns' construction):
1. Generate throwaway key pair: x ← random, X = x · G
2. Build tapscript:
OP_OVER <X> OP_CSFS OP_VERIFY OP_CTV3. Compute leaf hash: ℓ = HTapLeaf(0xc0 || script)
4. Compute tweak: t = HTapTweak(Xx || ℓ)
5. Compute output key: Q = X + t · G
6. Build CTV hash h for a tx sending value back to Q
7. Sign: (R, s) = Schnorr_sign(x, h)
8. Destroy x
Spending (every time, forever):
1. Witness: h, (R, s), script, control block
2. Script executes: OP_OVER duplicates h, OP_CSFS verifies sig on h, OP_CTV checks tx matches h
3. Output goes back to Q — the cycle repeats A perpetual self-spending covenant. The private key is gone; only the signature remains.
This construction uses every primitive covered in this section: finite field arithmetic, elliptic curve scalar multiplication, Schnorr signatures, tagged hashes, Taproot key tweaking, Merkle trees (single leaf), and the CTV template hash.