BIP 119 guide covering its Draft soft-fork status, transaction-template hash, OP_NOP4 semantics, covenant uses, validation costs, risks and safe evaluation.
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.
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.
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.
The BIP metadata labels it Consensus (soft fork), Specification and Draft. Any explanation must distinguish proposal behaviour from currently enforced mainnet consensus.
The proposal changes OP_NOP4 semantics. With activation rules enabled, a 32-byte stack item is compared with the DefaultCheckTemplateVerifyHash; a mismatch fails validation.
The hash commits to transaction version, locktime, scriptSig hash when relevant, input count, sequences hash, output count, outputs hash and the executing input index.
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.
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.
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.
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.
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.
The BIP metadata labels it Consensus (soft fork), Specification and Draft. Any explanation must distinguish proposal behaviour from currently enforced mainnet consensus.
The proposal changes OP_NOP4 semantics. With activation rules enabled, a 32-byte stack item is compared with the DefaultCheckTemplateVerifyHash.
The hash commits to transaction version, locktime, scriptSig hash when relevant, input count, sequences hash, output count, outputs hash and the executing input index.
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.
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
BIP 441 guide to the Draft tapleaf 0xC2 script-restoration proposal, varops, stack limits, unsigned arithmetic, restored opcodes and safety testing.
BIP 440 guide to the Draft transaction-wide variable-operation budget, weight scaling, opcode cost classes, benchmarks, validation and soft-fork status.
BIP 361 guide to the Draft informational post-quantum migration and legacy-signature sunset proposal, phases, prerequisites, risks and readiness planning.
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.