#31989 BIP-119 (OP_CHECKTEMPLATEVERIFY) (regtest only)

ReviewabilityReviewsAgreementSize
#31989 jamesob BIP-119 (OP_CHECKTEMPLATEVERIFY) (regtest only)Waiting on author0 (+1) -2Blocked244 + 3,439 tests
  • Allow covenant protocol developers to test BIP-119 transaction templates against Bitcoin Core in-tree
  • Enable testing interactions between OP_CHECKTEMPLATEVERIFY and other proposed soft-fork opcodes
  • Needs rebase and author response to long-standing objections before further review is worthwhile
  • Object to adding consensus rules without emergent community consensus (darosior, BitcoinErrorLog)
  • Warn of contentious chain split risks without clear community consensus (melvincarvalho, michaelfolkson)
  • Support for enabling covenant protocols and testing on non-production networks (jaybny, prasincs, ariard)
  • Code approval for implementation correctness and test coverage (rot13maxi, JeremyRubin)
  • 244 lines added or modified outside tests
  • 3,439 lines added or modified in tests
  • 23 lines removed in total
  • 33 files, 9 commits
Validation#19 of 53
P2 · new feature
  • P2 after comparing with the other PRs here (assessed alone as P1): Lowered to P2 to match the other regtest-only proposed-opcode implementations (#32247, #29247, #36122); no consensus change ships to users
  • P1 because it introduces consensus rules for a major proposed soft fork
  • It unblocks ecosystem evaluation of covenant designs without requiring custom out-of-tree builds
  • Thorough consensus review is critical to verify validation logic and caching correctness
Ranking notes
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

This PR implements BIP-119 (OP_CHECKTEMPLATEVERIFY, or CTV) by repurposing OP_NOP4, but limits its soft-fork deployment exclusively to regtest. It implements the template hash verification logic and caches the required hashes in transaction precomputation data. On non-regtest networks, CTV remains unactivated, maintaining existing NOP discouragement behavior.

Problem: Developers designing or experimenting with covenant protocols cannot test BIP-119 transaction templates against Bitcoin Core's codebase without custom out-of-tree builds. Additionally, testing how CTV interacts with other proposed soft-fork opcodes requires an in-tree implementation.

Evidence of importance:

  • Author description: "This implements BIP-119 (OP_CHECKTEMPLATEVERIFY), but only specifies a regtest deployment. There is no effective policy change, since the SCRIPT_VERIFY_* flags (as used) result in the same NOP-like behavior. This change can be composed with other opcode specifications (e.g. CSFS, CAT) and bundled into the same deployment (yet to be specified)."

Scope: The PR touches consensus validation and script interpreter code, but also includes over 3,000 lines of test vectors and functional test suites (notably ctvhash.json and feature_checktemplateverify.py).

Reviewability

Paused · Waiting on author

Open objections from BitcoinErrorLog, darosior, jaybny with no author reply for 434 days; review would repeat what has been asked.

Waiting on (from the thread read):

  • decision: social/community consensus before merging consensus rules into Core (objected by darosior, BitcoinErrorLog, melvincarvalho, michaelfolkson) 2025-07-07
  • decision: community and ecosystem consensus on introducing and activating CTV before merging consensus code into Core 2025-07-07
  • author: unanswered suggestion on requiring tx version 3+ to skip CTV cache computation 2025-03-13

Agreement

Blocked

objection that needs a change, nobody has replied (BitcoinErrorLog, melvincarvalho, darosior, michaelfolkson)

Thread notes: Re-evaluated under current schema rules. Converted r:2761957905 to a suggestion, added questions/suggestions from sedited, average-gary, and ariard's sigops attack claim, and brought all entries into compliance. / Updated the record to the current rules. Added missing questions and suggestions from sedited, moonsettler, jaybny, and average-gary. Assessed ariard's DoS hashing concern as directly answered by the author.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
BitcoinErrorLog (none)objection, scopeunsolicited modification of consensus rules without user demand or emergent consensusopenchangedno2025-03-05: 'this proposal represents an unsolicited modification of Bitcoin’s code and consensus rules. There is no clear user demand, no demonstrated market need, and no compelling application that justifies tak'
melvincarvalho (none)objection, safetyrisk of contentious chain split without clear user demand and community consensusopenchangedno2025-03-05: 'Any proposed change should be weighed against the worst-case scenario: civil war or a chain split, which we’ve seen before.'
sedited (contributor)question, maintenancewhether interpreter TODOs will be addressedanswered · author explained the TODO was premature and will remove the commentansweredyes2025-03-05: 'Are the TODOs going to be addressed here?'
Status from: 2025-03-05: jamesob: 'In this case, likely not - @JeremyRubin was initially thinking that if there was some way we could rule out use of OP_CTV in the script about to be evaluated'
moonsettler (none)suggestion, approachset m_bip119_ctv_ready to force instead of true and strip the superfluous if checkanswered · author clarifies force is for segwit/taproot detection but agrees the if check can be strippedansweredyes2025-03-05: 'Shouldn't it be set to `force` instead of `true`? Makes this if completely superfluous'
Status from: 2025-03-05: jamesob: 'no - `force` is simply the initial value for the segwit/taproot detection variables. Since there isn't a similar detection process for CTV, we must assume its cache prep is always required.'
darosior (member)objection, approachmerging consensus rules into Core before rough community consensus sets a bad precedent and dictates rulesopenchangedno2025-03-06: 'As this introduces a new consensus feature, it seems premature to merge this into Bitcoin Core until widespread consensus is reached among Bitcoin users to eventually activate this new feature in a so'
michaelfolkson (none)objection, safetymerging into Core acts as a step toward an activation attempt causing a potential chain splitopenchangedno2025-03-07: 'Merging this pull request would be a step towards a second declared activation attempt for CTV and a potential chain split if there isn't community consensus.'
jaybny (none)question, approachwhether this PR is a complete rewrite or a refactor of the original implementation from three years agoopenansweredno2025-03-08: 'clarify whether this pull request represents a complete rewrite or simply a refactor of the original implementation from three years ago'
moonsettler (none)suggestion, approachrequire tx.version 3 or higher for CTV to avoid unneeded cache computations when CTV could not be activeopenansweredno2025-03-13: 'Computation required by CTV ideally would not be carried out when CTV could not have been active. In this context the `tx.version` field is available.'
instagibbs (member)objection, correctnesszero functional consensus test coverage without defining a regtest deploymentfixed · fix pushed · author added a regtest-only deployment commitchangedyes2025-03-18: 'Currently there is zero consensus coverage at the functional level from what I can tell'
Status from: 2025-03-19: jamesob: 'Done in https://github.com/bitcoin/bitcoin/pull/31989/commits/5bb734b9d3628395c031fdf0eb0fbb249fe578e3.'
ariard (none)objection, approachdeploy CTV as a taproot op_success rather than legacy scriptaccepted · reviewer understood reasons for current design and later Concept ACKedansweredyes2025-04-12: 'I think it would be valuable to have CTV rather as a taproot op_success.'
Status from: 2025-08-24: ariard: 'I would support a change of CTV to be Taproot only, but I also understand the concern of the champions with the realities of the bitcoin ecosystem'
ariard (none)objection, safetycheap DoS vector where peers repeatedly broadcast max-block-weight CTV spends by tweaking 1 bit to force re-hashinganswered · author replied that standardness or PoW limits such spends and benchmarks show hashing is fast; reviewer pushed back but later Concept ACKedansweredyes2025-04-12: 'What prevents a peer to repeat broadcast of such ~MAX_BLOCK_WEIGHT tx CTV-spend to a target node ? Peer cost is just to tweaking some random 1-bit in the whole ~MAX_BLOCK_WEIGHT surface.'
Status from: 2025-04-15: jamesob: 'The processing of such a CTV-spend is either limited by standardness or PoW; standardness prohibits the relay of a large, non-mined CTV transaction'
average-gary (none)suggestion, correctnessreplace SetHexDeprecated with uint256::FromHex in ctvhash_tests.cppfixed · fix pushed · author incorporated the suggested uint256::FromHex test fix in a rebasechangedno2025-04-15: 'SetHexDeprecated() was recently removed in https://github.com/bitcoin/bitcoin/pull/32237 Possible resolution here:'
Status from: 2025-04-15: jamesob: 'adds @average-gary's `uint256::FromHex()` test change (and author credits).'
ariard (none)objection, safetyCTV use cases in legacy script can be broken by abusing the 80k segwit block sigops limitanswered · author replied this is a general legacy script limitation not specific to CTV; reviewer later accepted in Concept ACKansweredyes2025-06-10: 'You can break some CTV use-cases by abusing the segwit block limits (i.e the 80k limit sigops).'
Status from: 2025-06-12: jamesob: 'I don't see anything about your attack that's specific to CTV; e.g. your test script doesn't use the template hash or OP_NOP4 (OP_CTV).'

Support:

  • jaybny (none) (Concept ACK, 2025-03-08) [read]: CTV is an objectively well-reviewed, fundamental upgrade to Bitcoin with broad consensus among subject matter experts, providing scaling techniques without fundamentally altering Bitcoin
  • rot13maxi (none) (ACK, 2025-03-08) [both]: simple implementation, helpful comments, good test coverage, no backwards compatibility issues, passes all CI
  • moonsettler (none) (Concept ACK, 2025-03-08): ofc I Concept ACK [not substantive]
  • stevenroose (contributor) (Concept ACK, 2025-04-09) [read]: Concept ACK. There are a few things that look like rebase leftovers that are added and removed in the different commits. [not substantive]
  • jonatack (member) (Concept ACK, 2025-04-11): (no reason given) [not substantive]
  • JeremyRubin (contributor) (ACK, 2025-04-16) [read]: Reviewed, code seems correct and to match the old prs closely.
  • delta1 (none) (Concept ACK, 2025-06-09): Concept ACK. Will code review. [not substantive]
  • prasincs (none) (Concept ACK, 2025-06-09): Strongly support getting this in Regtest and Signet and doing further battle testing
  • average-gary (none) (Concept ACK, 2025-06-10): finds CTV desirable for condensing mining pool coinbase payouts to self-custodial addresses by deferring block space consumption
  • ariard (none) (Concept ACK, 2025-08-24) [read]: minimal extension of script capabilities allowing immutable vertices in transaction graphs useful for off-chain protocol designers

Participants:

  • 1440000bytes (none, neutral, 2 statements 2025-03-05 to 2025-03-08): shared covenant resources and commented on review process
  • BitcoinErrorLog (none, objection, 2 statements 2025-03-05 to 2025-07-26): Concept NACK; argues modification lacks user demand and emergent consensus
  • ariard (none, objection, 13 statements 2025-03-05 to 2025-08-24): raised DoS hashing and sigops overflow concerns; later gave Concept ACK
  • average-gary (none, support, 3 statements 2025-03-05 to 2025-06-10): Concept ACK for condensing mining pool payouts; suggested hex test fix
  • melvincarvalho (none, objection, 2 statements 2025-03-05 to 2025-03-05): opposes merging without overwhelming support, citing risk of chain split
  • moonsettler (none, support, 5 statements 2025-03-05 to 2025-03-13): Concept ACK; discussed sighash cache initialization logic
  • pinheadmz (member, neutral, 3 statements 2025-03-05 to 2025-06-10): moderation comments reminding reviewers to focus on code
  • sedited (contributor, question, 1 statements 2025-03-05 to 2025-03-05): asked whether interpreter TODOs would be addressed
  • willcl-ark (member, neutral, 1 statements 2025-03-05 to 2025-03-05): offered to moderate off-topic comments to external forums
  • darosior (member, objection, 2 statements 2025-03-06 to 2025-07-07): Concept NACK; argues Core should not merge consensus features before ecosystem consensus
  • michaelfolkson (none, objection, 2 statements 2025-03-07 to 2025-03-07): opposes merge as step toward contentious activation and chain split
  • jaybny (none, support, 1 statements 2025-03-08 to 2025-03-08): Concept ACK; considers CTV well-reviewed and ready for inclusion
  • rot13maxi (none, support, 1 statements 2025-03-08 to 2025-03-08): ACK; praised simple implementation, comments, and CI coverage
  • instagibbs (member, objection, 1 statements 2025-03-18 to 2025-03-18): noted lack of functional consensus coverage without a regtest deployment
  • stevenroose (contributor, support, 1 statements 2025-04-09 to 2025-04-09): Concept ACK; noted rebase leftovers
  • jonatack (member, support, 1 statements 2025-04-11 to 2025-04-11): Concept ACK
  • JeremyRubin (contributor, support, 3 statements 2025-04-16 to 2025-04-16): cr ACK; reviewed code correctness against earlier PRs
  • delta1 (none, support, 1 statements 2025-06-09 to 2025-06-09): Concept ACK
  • prasincs (none, support, 2 statements 2025-06-09 to 2025-06-09): Concept ACK for regtest and signet testing
  • stutxo (contributor, neutral, 1 statements 2025-08-17 to 2025-08-17): noted deployment bit overlap with the CSFS PR

Files

3447 lines under test/bench/ci.

  • src/test/data/ctvhash.json +2204/-0
  • test/functional/feature_checktemplateverify.py +738/-0
  • src/test/ctvhash_tests.cpp +203/-0
  • src/test/data/tx_valid.json +152/-0
  • src/script/interpreter.cpp +134/-7
  • src/test/data/tx_invalid.json +95/-0
  • src/script/interpreter.h +43/-4
  • test/functional/test_framework/messages.py +14/-0
  • src/validation.cpp +12/-1
  • test/functional/rpc_blockchain.py +13/-0
  • src/test/data/script_tests.json +5/-6
  • src/script/script.cpp +9/-1
  • src/test/versionbits_tests.cpp +6/-0
  • src/kernel/chainparams.cpp +5/-0
  • src/policy/policy.cpp +5/-0
  • src/script/script.h +4/-1
  • src/script/solver.cpp +5/-0
  • src/wallet/scriptpubkeyman.cpp +5/-0
  • src/deploymentinfo.cpp +4/-0
  • src/policy/policy.h +3/-1
  • src/rpc/blockchain.cpp +4/-0
  • src/rpc/rawtransaction.cpp +4/-0
  • test/functional/test_framework/script.py +2/-2
  • src/test/transaction_tests.cpp +3/-0
  • src/script/script_error.cpp +2/-0
  • src/test/CMakeLists.txt +2/-0
  • src/addresstype.cpp +1/-0
  • src/consensus/params.h +1/-0
  • src/script/script_error.h +1/-0
  • src/script/sign.cpp +1/-0
  • src/script/solver.h +1/-0
  • src/test/fuzz/script.cpp +1/-0
  • test/functional/test_runner.py +1/-0

Card

The short text the ranking pass compares across PRs.

This PR implements BIP-119 OP_CHECKTEMPLATEVERIFY (replacing OP_NOP4) but confines its activation strictly to regtest networks. It adds template hash calculation and precomputation into the script interpreter and standardizes bare CTV spending scripts on regtest while leaving mainnet and testnet verification unchanged. This enables testing and development of covenant workflows and composition with other proposed opcodes without altering mainnet consensus. Most of the diff consists of test vectors and functional tests for template verification.

Data

dossier JSON · extract JSON · model ledger, generated 2026-09-27T01:27, confidence high, input hash fa6714af1f1b994d
thread read through 2025-08-24 (55 statements), head 18d71b65db
labels: Consensus, Needs rebase, Needs Conceptual Review

Categories

Validation

P2 · new feature (assessed alone as P1; Lowered to P2 to match the other regtest-only proposed-opcode implementations (#32247, #29247, #36122); no consensus change ships to users)

This PR implements BIP-119 (OP_CHECKTEMPLATEVERIFY) consensus rules, which validation guidelines designate as high priority to evaluate and review for correctness regardless of whether or when mainnet activation occurs. Per the author, it implements template hash verification and caches required hashes in transaction precomputation data, resolving the problem where developers 'cannot test BIP-119 transaction templates against Bitcoin Core\'s codebase without custom out-of-tree builds.' Deliberate architectural decision and thorough review of soft-fork logic are critical to unblock covenant protocol evaluation.

Membership: Carries the Consensus label and adds BIP-119 script execution logic in src/script/interpreter.cpp and src/validation.cpp.

Factors: security/stability 1, bug 0, performance 0, user value 2, leverage 2