Antminer X9
Monero ASIC Miner
1000KH
HASHRATE
2.47W/KH
EFFICIENCY
2470W
POWER
£861.54
EST. MONTHLY
205
DAYS
EST. ROI
This guide explains BIP 119 CHECKTEMPLATEVERIFY in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 119 proposes OP_CHECKTEMPLATEVERIFY, usually shortened to CTV, as a consensus soft fork that gives a script a way to require a transaction to match a committed template hash. The BIP was assigned on 6 January 2020 and remains Draft.
- Why it matters: BIP 119 is a specific covenant proposal, not a general permission for arbitrary future rules. Its value and risk can be assessed only with its exact template commitments, Draft status and deployment boundary visible.
- Current position: The BIP was assigned on 6 January 2020 and remains Draft.
BIP 119 CHECKTEMPLATEVERIFY in simple English
BIP 119 CHECKTEMPLATEVERIFY: Committing to future transaction structure can support congestion-control trees, vault designs and other pre-planned spending paths with less interaction and stored presigned data.
Simple example
A node operator is checking BIP 119 CHECKTEMPLATEVERIFY. Test wrong input index, changed outputs, fee paths, nested templates, malformed stack elements and recovery before judging an application.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Soft fork:
- A proposed tightening of Bitcoin rules that old nodes may not enforce themselves.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Draft consensus status
The BIP metadata labels it Consensus (soft fork), Specification and Draft. Any explanation must distinguish proposal behaviour from currently enforced mainnet consensus.
Opcode behaviour
The proposal changes OP_NOP4 semantics. With activation rules enabled, a 32-byte stack item is compared with the DefaultCheckTemplateVerifyHash; a mismatch fails validation.
Template commitment
The hash commits to transaction version, locktime, scriptSig hash when relevant, input count, sequences hash, output count, outputs hash and the executing input index.
Covenant uses
Committing to future transaction structure can support congestion-control trees, vault designs and other pre-planned spending paths with less interaction and stored presigned data.
Limits and risks
Precise templates reduce flexibility, can create permanently unspendable outputs when constructed incorrectly and require careful fee and recovery design. The BIP discusses validation caching to avoid repeated hashing costs.
Soft-fork compatibility
Before activation, old semantics treat the opcode as a no-op subject to policy. Tightening an upgradable NOP is the proposed soft-fork mechanism, but activation itself requires separate network agreement and deployment.
Evaluation plan
Use isolated regtest or signet implementations, published vectors and adversarial templates. Test wrong input index, changed outputs, fee paths, nested templates, malformed stack elements and recovery before judging an application. Build a revision-pinned evidence pack on an isolated node, wallet or protocol harness.
Frequently asked questions
What is the main point of BIP 119 CHECKTEMPLATEVERIFY?
BIP 119 CHECKTEMPLATEVERIFY: Committing to future transaction structure can support congestion-control trees, vault designs and other pre-planned spending paths with less interaction and stored presigned data.
For BIP 119 CHECKTEMPLATEVERIFY, what should a beginner know about draft consensus status?
The BIP metadata labels it Consensus (soft fork), Specification and Draft. Any explanation must distinguish proposal behaviour from currently enforced mainnet consensus.
For BIP 119 CHECKTEMPLATEVERIFY, what should a beginner know about opcode behaviour?
The proposal changes OP_NOP4 semantics. With activation rules enabled, a 32-byte stack item is compared with the DefaultCheckTemplateVerifyHash.
For BIP 119 CHECKTEMPLATEVERIFY, what should a beginner know about template commitment?
The hash commits to transaction version, locktime, scriptSig hash when relevant, input count, sequences hash, output count, outputs hash and the executing input index.
Conclusion
BIP 119 is a specific covenant proposal, not a general permission for arbitrary future rules. Its value and risk can be assessed only with its exact template commitments, Draft status and deployment boundary visible.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.