BA-07 · LESSON 09

Covenant proposals

KEY DEFINITIONS

Terms used in this lesson

CTV: CheckTemplateVerify: a proposed covenant operation that would restrict a spend to a committed transaction template.
APO: ANYPREVOUT: a proposed signature-hash mode that would allow a signature to omit commitment to a specific prior output.
CAT: A proposed restoration of a Bitcoin Script operation that concatenates two byte strings.
ANYPREVOUT: A proposed signature-hash mode that would let a signature omit commitment to a specific prior output.
Vault: A set of Bitcoin outputs and spending rules that holds collateral and represents the current loan state.
BIP: Bitcoin Improvement Proposal: a numbered technical document describing a Bitcoin standard, process, or proposed change.

CTV, APO, CAT-related designs, and other proposals trade expressiveness, analyzability, and deployment risk.

35 min Difficulty 2/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · taproot treeAn internal key and hidden script tree commit one Taproot outputSelect any state to inspect its exact role.

RELATIONSHIP MAPCommitment and derivation tree

01
INTERNAL KEYX-only point P
The internal public key is combined with a tagged commitment to the script tree.
02
TAPTREETapLeaf and TapBranch
Leaf scripts are hashed and branches are ordered before hashing.
03
TWEAKH(P || root)
The tagged TapTweak hash becomes a scalar added to the internal key.
04
OUTPUT KEYCovenant proposals
The Covenant proposals lesson identifies which committed data must be reconstructed.
05
SPENDSignature or leaf proof
Key path reveals no script; script path reveals one leaf and its Merkle siblings.

Rule shown: A key-path signature or a revealed leaf plus control block must reconstruct the committed output key.

STAGE 1 OF 5INTERNAL KEY: X-only point P

The internal public key is combined with a tagged commitment to the script tree.

Governing relationship: A key-path signature or a revealed leaf plus control block must reconstruct the committed output key. Complete path: 1. INTERNAL KEY, X-only point P. The internal public key is combined with a tagged commitment to the script tree. 2. TAPTREE, TapLeaf and TapBranch. Leaf scripts are hashed and branches are ordered before hashing. 3. TWEAK, H(P || root). The tagged TapTweak hash becomes a scalar added to the internal key. 4. OUTPUT KEY, Covenant proposals. The Covenant proposals lesson identifies which committed data must be reconstructed. 5. SPEND, Signature or leaf proof. Key path reveals no script; script path reveals one leaf and its Merkle siblings.

1. State transitionWhat exists, what changes, and what results

BEFORE

An intended vault spend must create staging output S with a 144-block recovery delay before an unrestricted withdrawal.

MECHANISM

A vault might require funds to pass through a delayed staging output, while a congestion-control tree might commit many future payments.

AFTER

A covenant constrains transaction shape; it does not by itself solve key security, fee availability, or recovery.

Text equivalent: Starting from An intended vault spend must create staging output S with a 144-block recovery delay before an unrestricted withdrawal. The mechanism begins when A vault might require funds to pass through a delayed staging output, while a congestion-control tree might commit many future payments. The resulting lesson is A covenant constrains transaction shape; it does not by itself solve key security, fee availability, or recovery.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

State the desired future constraint

A vault might require funds to pass through a delayed staging output, while a congestion-control tree might commit many future payments.

Complete path: 1. State the desired future constraint: A vault might require funds to pass through a delayed staging output, while a congestion-control tree might commit many future payments. 2. Identify committed transaction fields: A template covenant can bind outputs, counts, version, locktime, or other structure. Exact commitment scope determines flexibility and bypass risk. 3. Compare proposal primitives: CTV checks a template hash. ANYPREVOUT changes signature commitment to previous outputs for protocols such as eltoo. CAT concatenates stack elements and can enable broader constructions with other operations. 4. Analyze recursion and escape paths: Some designs permit constraints to continue through successor outputs. Review whether funds can become trapped, whether emergency paths exist, and how fee funding works. 5. Evaluate deployment risk: Consensus changes need specifications, test vectors, implementations, activation design, review, and ecosystem support. A proposed opcode cannot be assumed available to current outputs.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

Each template, ANYPREVOUT, and CAT model names committed fields, successor constraints, recursion, escape and fee paths, plus pinned BIP document and deployment status.

CHANGED CONDITION

A staging bypass, no recovery delay, fee deadlock, missing escape, or undeployed primitive prevents the vault claim from passing.

Important distinction: All covenant proposals provide the same expressiveness and are already usable on Bitcoin mainnet. They commit to different data and enable different protocols. Proposed semantics require consensus deployment before ordinary users can rely on them.

Text equivalent: The accepted path is enforced by Each template, ANYPREVOUT, and CAT model names committed fields, successor constraints, recursion, escape and fee paths, plus pinned BIP document and deployment status. If the required condition changes, A staging bypass, no recovery delay, fee deadlock, missing escape, or undeployed primitive prevents the vault claim from passing.

Loading lesson visuals...

Learn the idea

A covenant restricts how a Bitcoin output may be spent, often by committing to properties of the future transaction. Bitcoin already has limited covenant-like effects through signatures and scripts, while proposals seek safer or more expressive constraints. CTV proposes committing to a transaction template, ANYPREVOUT proposes signature modes that omit a specific prior output, and CAT-related designs explore byte concatenation as a building block. These proposals differ and are not current general Bitcoin consensus rules.

GUIDED EXPLANATION1/5 ideas inspected

State the desired future constraint

A vault might require funds to pass through a delayed staging output, while a congestion-control tree might commit many future payments.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“All covenant proposals provide the same expressiveness and are already usable on Bitcoin mainnet.”

They commit to different data and enable different protocols. Proposed semantics require consensus deployment before ordinary users can rely on them.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.