{ "number": 31989, "repo": "bitcoin/bitcoin", "url": "https://github.com/bitcoin/bitcoin/pull/31989", "title": "BIP-119 (OP_CHECKTEMPLATEVERIFY) (regtest only)", "author": "jamesob", "author_association": "CONTRIBUTOR", "created_at": "2025-03-04T19:08:36Z", "updated_at": "2026-07-02T01:58:37Z", "age_days": 561, "draft": false, "labels": [ "Consensus", "Needs rebase", "Needs Conceptual Review" ], "milestone": null, "base": "master", "head_sha": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "head_ref": "2025-03-ctv", "head_repo": "jamesob/bitcoin", "head_history": [ { "t": "2025-03-04T20:00:35Z", "sha": "9aee5e7d584e67e7963b581c7106e45762193b51" }, { "t": "2025-03-05T01:38:12Z", "sha": "973a778d61ca72c8f2ad715383bad6a4500373c8" }, { "t": "2025-03-05T22:41:31Z", "sha": "c16ac82a8b4ddc7b483e0ba21bb5fef47ef839ce" }, { "t": "2025-03-05T23:04:39Z", "sha": "4c5790105e7fb3a2cd207403af769fbbccd7296d" }, { "t": "2025-03-20T03:53:30Z", "sha": "fc04582942c7e13d39909635df48af50b30ebc74" }, { "t": "2025-03-26T14:44:02Z", "sha": "693bb527ec1f98dcacf2c178a1c54a9deb90e85b" }, { "t": "2025-04-15T18:09:50Z", "sha": "5b57a696bc23860ac951a43c66e8e2ada453c4b3" }, { "t": "2025-04-15T18:20:48Z", "sha": "2b74adfb2001949c8f2bba17e5991aebd426127d" }, { "t": "2025-04-30T23:37:17Z", "sha": "915e0f32c1d201649380581ff253cbe8bee8f83d" }, { "t": "2025-05-12T15:37:44Z", "sha": "9184edbfe0484152ab84adb8e3887e0584646eb9" }, { "t": "2025-07-01T15:50:59Z", "sha": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf" } ], "additions": 3683, "deletions": 23, "changed_files": 33, "commit_count": 9, "size_bucket": "XL", "mergeable_state": "dirty", "bot": { "drahtbot": { "present": true, "reviews": { "concept_nack": [ { "login": "BitcoinErrorLog", "url": "https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-2700121604" }, { "login": "darosior", "url": "https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-3045062002" } ], "concept_ack": [ { "login": "jaybny", "url": "https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-2707892337" }, { "login": "moonsettler", "url": "https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-2708422352" }, { "login": "stevenroose", "url": "https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-2788109086" }, { "login": "jonatack", "url": "https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-2797288063" }, { "login": "delta1", "url": "https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-2955572099" }, { "login": "prasincs", "url": "https://github.com/bitcoin/bitcoin/pull/31989#pullrequestreview-2910009061" }, { "login": "pinheadmz", "url": "https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-2960013769" }, { "login": "average-gary", "url": "https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-2959839585" }, { "login": "ariard", "url": "https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-3218427453" } ], "stale_ack": [ { "login": "JeremyRubin", "url": "https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-2807950778" } ] }, "conflicts": [ { "number": 32998, "title": "Bump SCRIPT_VERIFY flags to 64 bit", "author": "ajtowns" }, { "number": 32729, "title": "test,refactor: extract script template helpers & widen sigop count coverage", "author": "l0rinc" }, { "number": 32453, "title": "[Policy] Discourage Unsigned Annexes", "author": "JeremyRubin" }, { "number": 29843, "title": "policy: Allow non-standard scripts with -acceptnonstdtxn=1 (test nets only)", "author": "ajtowns" }, { "number": 29247, "title": "CAT in Tapscript (BIP-347)", "author": "arminsabouri" }, { "number": 26201, "title": "Remove Taproot activation height", "author": "Sjors" } ] } }, "acks_parsed": { "BitcoinErrorLog": { "kind": "nack", "hash": null, "t": "2025-03-05T07:47:56Z", "stale": false }, "stevenroose": { "kind": "concept_ack", "hash": null, "t": "2025-04-09T02:10:09Z", "stale": false }, "jonatack": { "kind": "concept_ack", "hash": null, "t": "2025-04-11T15:41:58Z", "stale": false }, "delta1": { "kind": "concept_ack", "hash": null, "t": "2025-06-09T11:54:03Z", "stale": false }, "prasincs": { "kind": "concept_ack", "hash": null, "t": "2025-06-09T13:06:02Z", "stale": false }, "average-gary": { "kind": "concept_ack", "hash": null, "t": "2025-06-10T16:03:27Z", "stale": false } }, "acks_tally": { "ack": 0, "stale_ack": 0, "concept_ack": 5, "approach_ack": 0, "nack": 1, "concept_nack": 0, "approach_nack": 0 }, "reviews": { "approved": 0, "changes_requested": 0, "distinct_reviewers": [ "1440000bytes", "BitcoinErrorLog", "JeremyRubin", "ariard", "average-gary", "darosior", "delta1", "instagibbs", "jaybny", "jonatack", "melvincarvalho", "michaelfolkson", "moonsettler", "pinheadmz", "prasincs", "rot13maxi", "sedited", "stevenroose", "stutxo", "willcl-ark" ] }, "signals": { "needs_rebase": true, "ci_failed": false, "mergeable_state": "dirty", "last_author_activity": "2025-07-01T15:50:59Z", "last_reviewer_activity": "2025-08-24T22:47:00Z", "last_reviewer": "ariard", "author_silent_days": 443, "waiting_on_author_days": 388, "days_since_update": 77 }, "refs": { "mentioned": [], "depends_on": [], "fixes": [], "linked_issues": [], "references": [], "conflicts": [ 32998, 32729, 32453, 29843, 29247, 26201 ] }, "stack": { "shares_commits_with": [], "based_on": [], "base_for": [] }, "review_paths": [ "src/deploymentinfo.cpp", "src/script/interpreter.cpp", "src/script/interpreter.h", "src/test/ctvhash_tests.cpp" ], "body": "This implements [BIP-119 (`OP_CHECKTEMPLATEVERIFY`)](https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki), 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.\n\nThis change can be composed with other opcode specifications (e.g. [`CSFS`](https://bitcoinops.org/en/topics/op_checksigfromstack/), [`CAT`](https://bitcoinops.org/en/topics/op_cat/)) and bundled into the same deployment (yet to be specified).\n\nI encourage more general, conceptual discussion to happen on [Delving Bitcoin](https://delvingbitcoin.org/) and not on this pull request.\n\nSome related discussion on Delving Bitcoin here:\n- https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/\n\nSee also:\n- https://bitcoinops.org/en/topics/op_checktemplateverify/\n- https://utxos.org/", "commits": [ { "sha": "0cf7d5c65aea409754462d588ff7d008f7928c83", "date": "2025-07-01T15:43:39Z", "message": "Add StandardTemplateHash definition\n\nand associated SignatureChecker method." }, { "sha": "22549571de8f308903775f5d07f13465774bedae", "date": "2025-07-01T15:43:45Z", "message": "Add OP_CHECKTEMPLATEVERIFY Opcode as OP_NOP4\n\nAlso modifies script_tests.json to enable OP_NOP4 as OP_CHECKTEMPLATEVERIFY." }, { "sha": "c22e734693e20a52fb37f4ba61e796b2e5a8b12e", "date": "2025-07-01T15:43:46Z", "message": "script: precompute the DefaultCheckTemplateVerifyHash\n\nCo-authored-by: James O'Beirne " }, { "sha": "1ddb4bf3c33aa1f13706651c323da82a8c71d7ae", "date": "2025-07-01T15:43:47Z", "message": "policy: make bare OP_CHECKTEMPLATEVERIFY standard\n\nCo-authored-by: James O'Beirne " }, { "sha": "d51d32c63798364342486f37c976361b0c642e34", "date": "2025-07-01T15:43:47Z", "message": "test: add tx_valid.json tests for BIP-119 CheckTemplateVerify" }, { "sha": "e657a1c48bfc77508bf3c2bcdca5703a7118a092", "date": "2025-07-01T15:43:48Z", "message": "test: add tx_invalid.json examples for CTV" }, { "sha": "21742d65b0dd5749a51fe88d56d70b56ecbe24c9", "date": "2025-07-01T15:43:49Z", "message": "test: add CTV hash computation unit test & mutation tester\n\nCo-authored-by: James O'Beirne \nCo-authored-by: Gary Krause " }, { "sha": "ef21f316717bdb4f361f71854e2b87f8833439b1", "date": "2025-07-01T15:43:50Z", "message": "consensus: add a CTV deployment for regtest only" }, { "sha": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "date": "2025-07-01T15:47:57Z", "message": "test: add OP_CHECKTEMPLATEVERIFY functional tests\n\nCo-authored-by: James O'Beirne " } ], "timeline": [ { "t": "2025-03-04T20:00:35Z", "kind": "force_push", "who": "jamesob", "commit": "9aee5e7d584e67e7963b581c7106e45762193b51" }, { "t": "2025-03-05T01:38:12Z", "kind": "force_push", "who": "jamesob", "commit": "973a778d61ca72c8f2ad715383bad6a4500373c8" }, { "t": "2025-03-05T07:47:56Z", "kind": "comment", "who": "BitcoinErrorLog", "assoc": "NONE", "text": "NACK. As Towns just pointed out on the mailing list, this proposal represents an unsolicited modification of Bitcoin\u2019s code and consensus rules. There is no clear user demand, no demonstrated market need, and no compelling application that justifies taking on this risk. The absence of significant business interest or ecosystem momentum further underscores the speculative nature of this change.\n\nBitcoin\u2019s resilience depends on its conservatism. To safeguard against unnecessary complexity and centralized agenda-setting, we should reject rule changes that lack overwhelming, emergent consensus.\n\nUntil we establish clear standards for what constitutes legitimate consensus-driven changes and market-driven necessity, rather than academic or developer curiosity, proposals of this nature should be treated as research, not candidates for inclusion in Core." }, { "t": "2025-03-05T10:50:59Z", "kind": "comment", "who": "melvincarvalho", "assoc": "NONE", "text": "Echoing what @BitcoinErrorLog said\u2014clear user demand must be shown to justify this. Any proposed change should be weighed against the worst-case scenario: civil war or a chain split, which we\u2019ve seen before. The use case needs to be so compelling that it decisively outweighs these risks and gains overwhelming community support." }, { "t": "2025-03-05T11:20:48Z", "kind": "comment", "who": "1440000bytes", "assoc": "NONE", "text": "@BitcoinErrorLog @melvincarvalho\n\n[quoted text omitted]\nIn case you want to read other developers' evaluations of `CHECKTEMPLATEVERIFY` and its use cases, here are a couple of links:\n\nhttps://en.bitcoin.it/wiki/Covenants_support\nhttps://en.bitcoin.it/wiki/Covenants_Uses" }, { "t": "2025-03-05T14:28:20Z", "kind": "comment", "who": "willcl-ark", "assoc": "MEMBER", "text": "@jamesob I'd be happy to help you keep this thread focused by moderating off-topic comments and pointing them to the appropriate forums.\n\nYou've suggested and linked to Delving which seems appropriate for general/conceptual discussion, however there is no thread/post over there to actually point folks to.\nWould you mind starting a thread over there so that we have somewhere concrete to point these types of discussions to?" }, { "t": "2025-03-05T15:32:45Z", "kind": "comment", "who": "melvincarvalho", "assoc": "NONE", "text": "@1440000bytes wrote:\n\n[quoted text omitted]\nDiscussions related to this GitHub PR should remain on GitHub and the mailing list, where Bitcoin development has historically been debated and recorded. Moving discussions to multiple external platforms with different registration requirements, user bases, and change control mechanisms creates fragmentation and makes it harder to maintain a clear, consistent record of technical decisions.\n\nFor example, your [tweet from Jan 26](https://x.com/1440000bytes/status/1882194115598975308), which got 71 likes, demonstrates how statements made in one venue can later be deleted or altered, making it difficult to ensure accountability and track how discussions evolve over time.\n\n![image](https://github.com/user-attachments/assets/75a57479-f9e2-41a7-b243-2fe6837879ea)\n\nFurthermore, the belligerent posture some advocates have taken toward the Bitcoin Core project could be perceived as undermining the process, further increasing the risk of a contentious chain split\u2014a scenario that should be the primary concern of all Bitcoin developers.\n\nWhile external forums like Delving Bitcoin may be useful for general discussions, they are not officially part of the Bitcoin project and do not provide the same permanence or transparency as GitHub and the mailing list. To maintain clarity and continuity, technical discussions should remain in publicly archived, historically relevant venues with established change control." }, { "t": "2025-03-05T15:34:59Z", "kind": "comment", "who": "pinheadmz", "assoc": "MEMBER", "text": "@melvincarvalho please review the moderation policy: https://github.com/bitcoin-core/meta/blob/main/MODERATION-GUIDELINES.md\n\nGithub pull request review comments are restricted exclusively for PULL REQUEST REVIEW COMMENTS" }, { "t": "2025-03-05T17:22:12Z", "kind": "comment", "who": "average-gary", "assoc": "NONE", "text": "[quoted text omitted]\n\nhttps://delvingbitcoin.org/t/bip-119-op-checktemplateverify-no-activation/1494" }, { "t": "2025-03-05T20:24:21Z", "kind": "review_comment", "who": "sedited", "assoc": "CONTRIBUTOR", "path": "src/script/interpreter.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": null, "text": "Are the TODOs going to be addressed here?" }, { "t": "2025-03-05T22:18:33Z", "kind": "review_comment", "who": "jamesob", "assoc": "CONTRIBUTOR", "path": "src/script/interpreter.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": 1982137766, "text": "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, we could forgo warming the caches below. But (aside from that being probably impossible) this TODO was made [prior to benchmarking](https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1026922813) that shows there isn't any detectable slowdown to initializing those caches.\n\nI'll remove the comment." }, { "t": "2025-03-05T22:38:49Z", "kind": "review_comment", "who": "moonsettler", "assoc": "NONE", "path": "src/script/interpreter.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": 1982137766, "text": "Shouldn't it be set to `force` instead of `true`?\n\nMakes this if completely superfluous:\n```c++\n if (uses_bip143_segwit || uses_bip341_taproot || uses_bip119_ctv) {\n // Computations shared between both sighash schemes.\n m_prevouts_single_hash = GetPrevoutsSHA256(txTo);\n m_sequences_single_hash = GetSequencesSHA256(txTo);\n m_outputs_single_hash = GetOutputsSHA256(txTo);\n\n // 0 hash used to signal if we should skip scriptSigs\n // when re-computing for different indexes.\n m_scriptSigs_single_hash = NoScriptSigs(txTo) ? uint256{} : GetScriptSigsSHA256(txTo);\n m_bip119_ctv_ready = true;\n }\n```" }, { "t": "2025-03-05T22:41:31Z", "kind": "force_push", "who": "jamesob", "commit": "c16ac82a8b4ddc7b483e0ba21bb5fef47ef839ce" }, { "t": "2025-03-05T22:47:47Z", "kind": "review_comment", "who": "jamesob", "assoc": "CONTRIBUTOR", "path": "src/script/interpreter.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": 1982137766, "text": "@moonsettler 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. But that's a good point that it's probably worthwhile to strip out the `if`.\n\nLikely the only way we could make `use_bip119_ctv` actually variable is on the basis of activation height. Hence the original TODO." }, { "t": "2025-03-05T22:53:02Z", "kind": "comment", "who": "ariard", "assoc": "NONE", "text": "[quoted text omitted]\n\n@jamesob see my pending email in answer to AJ for the issues with CSFS building on @naumenkogs\u2019s TxWithhold:\n- https://blog.bitmex.com/txwithhold-smart-contracts/\n- https://gnusha.org/pi/bitcoindev/f594c2f8-d712-48e4-a010-778dd4d0cadb@Spark/\n\nEspecially if it\u2019s possible to do a TxWithhold on the spend of any coinbase output beyond `COINBASE_MATURITY`. At least having an impossibility result that you cannot do a TxWithhold by grinding the miner\u2019s scriptpubkey would be welcome from a safe engineering perspective. I\u2019m not able to come with a practical offensive TxWithhold with OP_CTV alone, though as soon as you combine it with another primitive this is plausible." }, { "t": "2025-03-05T23:03:53Z", "kind": "review_comment", "who": "moonsettler", "assoc": "NONE", "path": "src/script/interpreter.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": 1982137766, "text": "[quoted text omitted]\n\nSounds better than nothing." }, { "t": "2025-03-05T23:04:39Z", "kind": "force_push", "who": "jamesob", "commit": "4c5790105e7fb3a2cd207403af769fbbccd7296d" }, { "t": "2025-03-05T23:44:26Z", "kind": "comment", "who": "pinheadmz", "assoc": "MEMBER", "text": "@ariard I think your comment is more appropriate on the mailing list or delving. You are even mentioning a specific post from the mailing list. I expect a lot of off-topic comments on this PR and would appreciate your help staying focused. PR comments MUST be entirely focused on THIS PR code." }, { "t": "2025-03-06T19:47:36Z", "kind": "comment", "who": "ariard", "assoc": "NONE", "text": "@pinheadmz Sure, the conceptual aspects of this PR are better discussed on the mailing list or delving or even on nostr with no moderators. Generally, this is up to the PR author to indicate on which communication channel, they have posted the conceptual motivation of a code change for discussion. Here we have a code change motivated by other arguments (bundle OP_CSFS, OP_CAT) which are not mentioned on the Delving Bitcoin thread itself, and as such making the conversation on the technical rational of the change _incomplete_ in itself.\n\nI\u2019ll silence that any conceptual review of a change has to be founded on the code itself, and doing back and forth between the code and the technical concepts is most of the time very insightful. I\u2019m sure that something that you Pineheadmz you\u2019re aware of as an experienced reviewer on Bitcoin Core code itself, well-known in this space for your technical contributions.\n\nFinally, if this PR got reviewed elsewhere on another repository than the Bitcoin Core one, this is my pleasure to have the technical discussion on CTV and any corresponding technical review there." }, { "t": "2025-03-06T20:35:49Z", "kind": "comment", "who": "darosior", "assoc": "MEMBER", "text": "The code in this pull request is of good quality and is well tested, but it's not clear to me what's the goal with this pull request nor how it fits in the big picture. 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 soft fork.\n\nTo be clear, i am not saying the details of the activation need to be figured out before the implementation of the feature goes in, but there needs to at least be rough consensus among Bitcoin users to activate this at all." }, { "t": "2025-03-07T09:55:46Z", "kind": "comment", "who": "michaelfolkson", "assoc": "NONE", "text": "[quoted text omitted]\n\n[quoted text omitted]\nTo state the obvious if you push \"conceptual discussion\" (a critical part of the Bitcoin Core review process for a PR) to external forums (why not an accompanying issue in this repo?) the consideration of whether to merge this pull request would require monitoring these external forums. 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. Pushing that conceptual discussion outside of this repo doesn't change that fact." }, { "t": "2025-03-07T11:08:54Z", "kind": "comment", "who": "moonsettler", "assoc": "NONE", "text": "We are going to activate CTV I don't think that's a question. The question is will core merge it in before or after lock-in?" }, { "t": "2025-03-07T11:15:57Z", "kind": "comment", "who": "michaelfolkson", "assoc": "NONE", "text": "[quoted text omitted]\n\nIf you don't care about the Bitcoin Core review process, community consensus and causing chain splits probably better you close this PR and attempt to cause chaos in a different repo." }, { "t": "2025-03-08T00:15:27Z", "kind": "comment", "who": "1440000bytes", "assoc": "NONE", "text": "This pull request is last attempt IMO to get some \"technical reviews\" and find bugs.\n\nIt will obviously get merged when community wants to use it and looking for activation." }, { "t": "2025-03-08T02:00:16Z", "kind": "comment", "who": "jaybny", "assoc": "NONE", "text": "Before proceeding with a full technical review, I\u2019d like to clarify whether this pull request represents a complete rewrite or simply a refactor of the original implementation from three years ago.\n\n----------------------------\n\nOff-topic\n\n**Concept ACK**\n\nCTV is an objectively well-reviewed, fundamental upgrade to Bitcoin, and it has gained broad consensus among subject matter experts over the past three years. There will only ever be a handful of legitimate, code-complete upgrades to Bitcoin that are truly ready for merge\u2014and this is one of them, an ingenious, well-thought-out enhancement to Bitcoin with no downside.\n\nI disagree with the notion that consensus-breaking code should receive special treatment compared to other changes. Every upgrade to Bitcoin carries some risk of unknowns (after all, the bug that caused the chain split in 2010 wasn\u2019t consensus code). Moreover, not every low-level piece of C++ code needs to be judged solely on market demand. In Bitcoin, the only reason some people focus their complaints on consensus-breaking code is because such changes require a broad social activation method\u2014to ensure miners are informed, upgrade their nodes, and keep the network in sync to avoid a chain split. This process isn\u2019t a social vote; it\u2019s simply a way of signaling to the hardware operators that Bitcoin software must be upgraded and indicating when it is safe to activate.\n\nFrankly, the only reason this ends up on the non-technical timeline is because social consensus is needed to get the word out to miners. Otherwise, like the hundreds of other low-level Bitcoin Core C++ code merges, this wouldn\u2019t attract such uninformed commentary.\n\nWhile there\u2019s naturally a significant overlap between consensus code and Bitcoin\u2019s core fundamentals, BIP119 provides additional scaling techniques and supports second-layer mechanisms without fundamentally altering Bitcoin itself.\n\nUltimately, mergeable C++ code that has undergone thorough review and reached technical consensus should be merged in a timely manner to avoid staleness\u2014even if activation debates continue elsewhere.\n\nGiven the limited number of humans capable of writing and reviewing low-level C++ Bitcoin upgrades, I hope this is the last time we code and review the same feature in the same codebase.\n\nUnless there are substantive technical issues, I recommend we focus on the code review here and move broader conceptual discussions to the appropriate forums." }, { "t": "2025-03-08T02:27:00Z", "kind": "comment", "who": "rot13maxi", "assoc": "NONE", "text": "simple implementation, helpful comments, good test coverage, no backwards compatibility issues, passes all CI.\n\nLGTM!" }, { "t": "2025-03-08T18:04:25Z", "kind": "comment", "who": "moonsettler", "assoc": "NONE", "text": "I don't know how many times we have played this game, but on a positive note ofc I Concept ACK" }, { "t": "2025-03-12T20:08:12Z", "kind": "comment", "who": "jamesob", "assoc": "CONTRIBUTOR", "text": "I've added a link to the active [Delving Bitcoin discussion](https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/23) most pertaining to CTV, and will keep the PR description above updated with any other relevant discussions." }, { "t": "2025-03-13T12:02:34Z", "kind": "review_comment", "who": "moonsettler", "assoc": "NONE", "path": "src/script/interpreter.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": null, "text": "Computation required by CTV ideally would not be carried out when CTV could not have been active.\nIn this context the `tx.version` field is available. If CTV (or at least bare CTV) required version 3 or higher (not sure this is a good idea or not?), then it would be trivial to augment the old logic that was more conservative with resource use. (again not sure how much that matters in practice?)" }, { "t": "2025-03-18T19:12:23Z", "kind": "comment", "who": "instagibbs", "assoc": "MEMBER", "text": "I suggest a regtest-only deployment is defined so functional testing can be re-instated. Currently there is zero consensus coverage at the functional level from what I can tell: https://github.com/bitcoin/bitcoin/pull/31989/commits/4c5790105e7fb3a2cd207403af769fbbccd7296d" }, { "t": "2025-03-19T20:25:09Z", "kind": "comment", "who": "jamesob", "assoc": "CONTRIBUTOR", "text": "[quoted text omitted]\n\nDone in https://github.com/bitcoin/bitcoin/pull/31989/commits/5bb734b9d3628395c031fdf0eb0fbb249fe578e3." }, { "t": "2025-03-20T03:53:30Z", "kind": "force_push", "who": "jamesob", "commit": "fc04582942c7e13d39909635df48af50b30ebc74" }, { "t": "2025-03-26T14:44:02Z", "kind": "force_push", "who": "jamesob", "commit": "693bb527ec1f98dcacf2c178a1c54a9deb90e85b" }, { "t": "2025-04-09T02:10:09Z", "kind": "comment", "who": "stevenroose", "assoc": "CONTRIBUTOR", "text": "Concept ACK. There are a few things that look like rebase leftovers that are added and removed in the different commits." }, { "t": "2025-04-11T15:41:58Z", "kind": "comment", "who": "jonatack", "assoc": "MEMBER", "text": "Concept ACK" }, { "t": "2025-04-12T02:15:00Z", "kind": "review_comment", "who": "ariard", "assoc": "NONE", "path": "src/script/interpreter.h", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": null, "text": "minor: I think all mention to \u201cStandard\u201d template can be removed and just `s/standard/default/g` or `s/standard/primary/g`. We have already `IsStandard` as a checker utility for policy sanitization, though here IIUC it\u2019s meant to be \u201cstandard\u201d as the default template hash 32-byte as told by BIP 119, which does not preclude future template that wouldn\u2019t be necessarily the default 32-byte one." }, { "t": "2025-04-12T02:42:08Z", "kind": "review_comment", "who": "ariard", "assoc": "NONE", "path": "src/script/interpreter.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": null, "text": "If I\u2019m understanding the biggest transaction size that can be verified by an OP_CTV is equal to ~`MAX_BLOCK_WEIGHT`.`\n\nWhile there is a limit on the max transaction size (`MAX_STANDARD_TX_WEIGHT`), this a transaction-relay only limit and if a miner is accepting non-standard tx, and there are of course some, a ~`MAX_BLOCK_WEIGHT` size transaction can be given as spending a CTV-locked input.\n\nMoreover, currently there are only 2 caches in bitcoin core to speed up the validation of a transaction (`SignatureCache`) and (`m_script_execution_cache`). IIRC, they both commit to the transaction hash spends with by a `uint256 entry`. So if a ~`MAX_BLOCK_WEIGHT` changes for 1-bit, I think there will be a re-computation of the hash for the whole ~`MAX_BLOCK_WEIGHT`.\n\nWhat 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. Note, I believe the max size hashing you can do (i.e `OP_HASH256`) is limited by `MAX_STACK_SIZE`. I\u2019m not sure this is considered in the BIP." }, { "t": "2025-04-12T02:43:38Z", "kind": "review", "who": "ariard", "assoc": "NONE", "state": "COMMENTED", "commit": "693bb527ec1f98dcacf2c178a1c54a9deb90e85b", "text": "I think it would be valuable to have CTV rather as a taproot op_success.\n\nThere has been a proof-of-concept branch done here:\nhttps://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/58" }, { "t": "2025-04-15T15:01:42Z", "kind": "review_comment", "who": "average-gary", "assoc": "NONE", "path": "src/test/ctvhash_tests.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": null, "text": "`SetHexDeprecated()` was recently removed in https://github.com/bitcoin/bitcoin/pull/32237\n\nPossible resolution here:\n```\n auto opt_hash = uint256::FromHex(hash_arr[i].get_str());\n if (!opt_hash) {\n\n BOOST_ERROR(\"Bad test: Invalid hex string\" << strTest);\n continue;\n }\n hash.push_back(*opt_hash);\n```" }, { "t": "2025-04-15T18:04:07Z", "kind": "review_comment", "who": "jamesob", "assoc": "CONTRIBUTOR", "path": "src/script/interpreter.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": 2040517393, "text": "[quoted text omitted]\n\nThe processing of such a CTV-spend is either limited by standardness or PoW; standardness prohibits the relay of a large, non-mined CTV transaction, and in the other case network-difficulty PoW will materially limit the number of times a node has to hash 4MB worth of transaction data.\n\nAnd anyway, hashing 4MB of transaction data is substantially faster than checking signatures for a correspondingly sized block full of sigops; see [this rough benchmark](https://gist.github.com/jamesob/02d3755b7bc34c10d57caef36535f637):\n```\n % g++ -o bench bench.cpp -lsecp256k1 -lcrypto -std=c++17 && ./bench\n\nGenerating 4MB of random data for hashing...\nPreparing 32768 signatures for validation benchmark...\nRunning SHA-256 benchmark...\nRunning signature validation benchmark...\n\n=== BENCHMARK RESULTS ===\nData size: 4 MB\nNumber of signatures: 32768 (1MB)\n\nSHA-256 hashing time: 2.15 ms\nSignature validation time: 1084.43 ms\n\nRatio (validation/hashing): 504.51x\n```" }, { "t": "2025-04-15T18:09:50Z", "kind": "force_push", "who": "jamesob", "commit": "5b57a696bc23860ac951a43c66e8e2ada453c4b3" }, { "t": "2025-04-15T18:20:48Z", "kind": "force_push", "who": "jamesob", "commit": "2b74adfb2001949c8f2bba17e5991aebd426127d" }, { "t": "2025-04-15T18:38:03Z", "kind": "comment", "who": "jamesob", "assoc": "CONTRIBUTOR", "text": "I've pushed a rebase that\n- simplifies the commit structure,\n- removes some of the intra-commit whitespace/indent changes,\n- adds @average-gary's `uint256::FromHex()` test change (and author credits)." }, { "t": "2025-04-16T01:21:00Z", "kind": "review_comment", "who": "JeremyRubin", "assoc": "CONTRIBUTOR", "path": "src/script/interpreter.h", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": null, "text": "nit: can these be converted to span to minimize the diff on the next commit?" }, { "t": "2025-04-16T01:22:17Z", "kind": "review_comment", "who": "JeremyRubin", "assoc": "CONTRIBUTOR", "path": "src/script/interpreter.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": null, "text": "nit: can this be moved to the last patch? edit: by last, i mean prior. Can NoScriptSigs be introduced in the first commit" }, { "t": "2025-04-16T01:31:31Z", "kind": "comment", "who": "JeremyRubin", "assoc": "CONTRIBUTOR", "text": "Reviewed, code seems correct and to match the old prs closely.\n\ncr ACK [2b74adf](https://github.com/bitcoin/bitcoin/pull/31989/commits/2b74adfb2001949c8f2bba17e5991aebd426127d)\n\nwill re-review as necessary" }, { "t": "2025-04-18T00:03:12Z", "kind": "review_comment", "who": "ariard", "assoc": "NONE", "path": "src/script/interpreter.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": 2040517393, "text": "Thanks for the `bench.cpp`, I had a look on `benchmark_sha256` and `benchmark_signature_validation`.\n\nThough here few more thoughts on the 1-bit cost from the view of a DoSing peer.\n\nCurrently, we have 2 caches the signature cache and the `m_script_execution_cache`.\n\nIf a script has already an entry at `CheckInputScripts()`, bitcoin core returns true:\nhttps://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2185\n\nIf there is already a cache entry, and the script includes signatures (and I believe all scripts currently used for spends are using an asymmetric keypair as a lock), all the signatures are going to be pre-processed by the `SignatureChecker`: https://github.com/bitcoin/bitcoin/blob/master/src/script/sigcache.cpp#L63 (ECDSA) or https://github.com/bitcoin/bitcoin/blob/master/src/script/sigcache.cpp#L76 (Schnorr).\n\nFrom the view of the DoSing peer, currently if you\u2019re doing DoS with a script-based signature, for each signature associated with a pubkey committed in a redeemscript, there is a computing cost to generate fresh signature, as one has to re-generate a DER-encoded signature of the same length (`IsValidSignatureEncoding()` i.e > 9 bytes or < 73 bytes or `CheckSchnorrSignature()` i.e 64 or 65 byte), even if the signature verification check yields it\u2019s consensus invalid. Relayed and announced invalid transactions are cached in the `m_inventory_known_filter`.\n\nWith a world with a hash-only lock, this is not the same computing cost anymore at all for a DoSing peer, as there is just one 1-bit to tweak in the whole CTV `MAX_BLOCK_WEIGHT` block. On the other hand, a signature-based DoS, you\u2019re very quickly limited by the size and malleability space of the signature, which it\u2019s itself constrained by the pubkey type committed in an already confirmed coin (when it\u2019s not a chain of tx validated in the same block).\n\nIf this reasoning is correct, and please point out if there are not flaws, I could be worthy to add some policy-only rule for CTV spend, e.g `MAX_CTV_INPUT_SPEND_WEIGHT` or something similar, that can be accordingly adjusted in the idea.\n\nI have no idea in terms of inputs what is the biggest transactions considered for a CTV-spend for hypothetical CTV use-cases so far." }, { "t": "2025-04-18T00:17:47Z", "kind": "comment", "who": "ariard", "assoc": "NONE", "text": "[quoted text omitted]\n\nSo I\u2019ve re-read the current version of BIP119 as available in the BIP repository, there is a section about the usage of OP_NOP (`NOP-Default and Recommended Standardness Rules`), however it doesn\u2019t say among the NOP upgradable path and the current upgrade path available with Taproot OP_SUCCESS or an upgrade of the tapscript version.\n\nI\u2019m aware that CTV was designed and drafted for standard, before Taproot got activated. However, it would benefit for _composability_ with future opcodes or if a use-case wish to compose CTV semantics + schnorr verification (e.g ` `.\n\nNon-malleable Schnorr signature verification combined with a CTV check is something clearly any use-case could be interested to build on, or at least to have that level of _expressivity_. Not sure, if it has been considered somewhere else, e.g in the BIP 119 footnote or else." }, { "t": "2025-04-30T23:37:17Z", "kind": "force_push", "who": "jamesob", "commit": "915e0f32c1d201649380581ff253cbe8bee8f83d" }, { "t": "2025-05-12T15:37:44Z", "kind": "force_push", "who": "jamesob", "commit": "9184edbfe0484152ab84adb8e3887e0584646eb9" }, { "t": "2025-06-04T21:21:17Z", "kind": "comment", "who": "ariard", "assoc": "NONE", "text": "the rational why it can be valuable to make CTV a P2TR upgrade only for CTV+sig kind of redeem script\n\nhttps://github.com/lightning/bolts/issues/1266" }, { "t": "2025-06-09T11:54:03Z", "kind": "comment", "who": "delta1", "assoc": "NONE", "text": "Concept ACK. Will code review." }, { "t": "2025-06-09T13:03:23Z", "kind": "review_comment", "who": "prasincs", "assoc": "NONE", "path": "src/deploymentinfo.cpp", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": null, "text": "Possibly nit: since other elements in the array are using designated initializers, commenting the field names isn't necessary. Since the prior element in array would fail to compile on < C++20" }, { "t": "2025-06-09T13:06:02Z", "kind": "review", "who": "prasincs", "assoc": "NONE", "state": "COMMENTED", "commit": "9184edbfe0484152ab84adb8e3887e0584646eb9", "text": "Concept ACK. Strongly support getting this in Regtest and Signet and doing further battle testing" }, { "t": "2025-06-10T16:03:27Z", "kind": "comment", "who": "average-gary", "assoc": "NONE", "text": "Concept ACK.\nI find CTV desirable for [condensing mining pool coinbase payouts](https://delvingbitcoin.org/t/scaling-noncustodial-mining-payouts-with-ctv/1753) to many self-custodial addresses by deferring block space consumption until it is more economically feasible." }, { "t": "2025-06-10T17:04:39Z", "kind": "comment", "who": "pinheadmz", "assoc": "MEMBER", "text": "In an effort to keep pull requests focused on technical discussion, I invite all contributors of conceptual review to post here:\n\nhttps://github.com/bitcoin-core/meta/discussions/28\n\nPlease try to keep pull request comments focused on the code changes, and move all other comments including \"concept N/ACK\" to the discussion page." }, { "t": "2025-06-10T20:16:38Z", "kind": "comment", "who": "ariard", "assoc": "NONE", "text": "@jamesob You can break some CTV use-cases by abusing the segwit block limits (i.e the 80k limit sigops).\n\nHere a test case on some 28.x branch, i.e `getblocktemplate` won\u2019t accept more txn, once 80k limit reached)\nhttps://github.com/ariard/bitcoin/commit/b85a426c43cb7000788a55ea140b73a68da9ce4e\n\nAn adversary can be break-even by targeting multiples \u201ccontract protocols\u201d in overflowing a single sequence of blocks.\n\nThe easy fix is to move CTV as an OP_SUCCESS, as like it\u2019s done for OP_CSFS.\n\nTouched a word to Jeremy about that problem when was in Vegas, though I\u2019ve been sleeping on that since a while...\n\nIf I\u2019m wrong owe you a beer next time but too I\u2019m far too lazy to go to write a full-explanation on the ML \ud83e\udd37" }, { "t": "2025-06-11T00:42:24Z", "kind": "comment", "who": "ariard", "assoc": "NONE", "text": "[quoted text omitted]\n\nwell i went to publish a full write up of that on the ML, because I like James and he\u2019s someone with integrity.\n\ni think the problem is real, but don\u2019t trust, verify." }, { "t": "2025-06-12T00:02:30Z", "kind": "comment", "who": "jamesob", "assoc": "CONTRIBUTOR", "text": "@ariard thanks - probably the place for that is the meta issue or Delving Bitcoin. 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). Rather it seems like a limitation of legacy script in general. But let's move this discussion off this PR please." }, { "t": "2025-06-13T01:36:23Z", "kind": "comment", "who": "ariard", "assoc": "NONE", "text": "[quoted text omitted]\n\n@jamesob It\u2019s correct it\u2019s not specific for CTV, though it\u2019s easy for CTV to fix it. The test case doesn\u2019t use the template hash, but the \u201ceffect\u201d should be the same when OP_NOP4. Yeah, let\u2019s discuss the fix on your core GH repository better." }, { "t": "2025-06-29T21:50:36Z", "kind": "comment", "who": "ariard", "assoc": "NONE", "text": "Opened a pull request on Jamesob repository with the suggested changes: due to current block sigs exhaustions exposure:\nhttps://github.com/jamesob/bitcoin/pull/3\n\nChanges motivated by current exposure to block signature overflow attacks and it\u2019s quite simple to fix." }, { "t": "2025-07-01T15:50:59Z", "kind": "force_push", "who": "jamesob", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf" }, { "t": "2025-07-07T13:16:33Z", "kind": "comment", "who": "darosior", "assoc": "MEMBER", "text": "I [believe](https://gnusha.org/pi/bitcoindev/F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI=@protonmail.com/) the ability to commit to the transaction to spend an output, combined with BIP340 signature verification of arbitrary messages, is a reasonable bundle of capabilities to consider for a Bitcoin soft fork. However there is clearly no consensus about this among the Bitcoin development community (see for instance [here](https://gnusha.org/pi/bitcoindev/aEu8CqGH0lX5cBRD@erisian.com.au) and [here](https://gnusha.org/pi/bitcoindev/8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com) for recent examples). On top of disagreement regarding the capability itself, [objections](https://gnusha.org/pi/bitcoindev/b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com/) were raised about CTV's approach to implement it.\n\nBitcoin Core should implement but not dictate Bitcoin's consensus rules. As such, a Bitcoin soft fork should only be implemented in Bitcoin Core *after* there is (rough) consensus among the Bitcoin developer community, and preferably after there is also demonstrated support from Bitcoin users. Outstanding disagreements to CTV on both conceptual and specifications ground make it absolutely premature to consider it for inclusion into Bitcoin Core.\n\nThe repeated attempts by the author of this PR to try to pressure his way to getting this change merged also leads me to believe he's trying to take advantage of Bitcoin Core's position as the dominant Bitcoin full node implementation to circumvent the broader consensus process. I think such an attempt would ultimately fail, but should be opposed rather than facilitated by the Bitcoin Core project on the sole ground that it would set a terrible precedent for how we approach changes to Bitcoin's consensus rules.\n\nFor all these reasons, Concept NACK on merging this pull request.\n\nTo be clear, i am not arguing this PR needs necessarily be closed. I understand a pull request to Bitcoin Core has uses beyond requesting being pulled into master, for instance to keep an up-to-date implementation of the proposal with already configured CI to point people to. But in my opinion marking it as draft would better indicate its status." }, { "t": "2025-07-26T17:27:05Z", "kind": "comment", "who": "BitcoinErrorLog", "assoc": "NONE", "text": "[quoted text omitted]\n\nThis is not sufficient for inclusion into the most popular implementation.\n\nDevelopers are not a governance system for Bitcoin. Higher standards must be defined, required, and culturally acceptable." }, { "t": "2025-08-17T00:02:35Z", "kind": "review_comment", "who": "stutxo", "assoc": "CONTRIBUTOR", "path": "src/script/interpreter.h", "commit": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "in_reply_to": null, "text": "fyi this is the same bit used for csfs PR https://github.com/bitcoin/bitcoin/pull/32247" }, { "t": "2025-08-24T22:47:00Z", "kind": "comment", "who": "ariard", "assoc": "NONE", "text": "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nConcept ACK.\n\nI'm not going to enter into the polemic about what should be or not the broader consensus process.\nDuring the year of 2022 and 2023, in reaction to the failed CTV activation attempt, I did launch\nand maintain for roughly a year the bitcoin contracting WG on IRC open to everyone, as a transparent\nforum to discuss consensus changes, in the goal to make real and step-by-step progress among all the\ndomain experts.\n\nWhile, I did discontinue this effort to spend more time investigating security bugs (there is only\n144 blocks in a day...but an infinite universe of way to break things...*sighs*), there has been\nalmost none other initiatives to move the needle forward, apart of still bitcoin-inquisition and\none or two playbooks to describe what \"ideally\" should be the process, but who have not been applied\nby their authors as far as I'm aware off.\n\nI have no opinion if bitcoin core is or not the dominant full node implementaiton in the bitcoin\necosystem. It might the case at the current block (i.e 911544), it might not be the case anymore\nat the next block, 10 min in average. As far as I know there is no trustless cryptograpghic protocol\nto prove with near-zero latency the identity of the software you're running to an open set of verifiers\nall over the world.\n\nGiven the champion of this proposed consensus change, CHECKTEMPLATEVERIFY, have opened the code here\nfor review against a version of the bitcoin consensus engine code, and that consensus change is ultimately\na process where a group of human beings decide which technical rules will be authoritatively run by\na network of computers nodes, we're stuck on this online forum of discussion, in the lack of a better one.\n\nWith all those elements in mind, I'm not the Pythia of Delphi, so in the lack of a more formalized\nconsensus process, I'll only speak further for myself as I don't know how to interprets the entrails\nof the bitcoin community like Greek oracles used to do in the ancient Greece.\n\nOn the design of CHECKTEMPLATEVERIFY, of which, describing in my own words allows to build \"hash-chain\"\nof transactions, where a spending transaction must equal a pre-committed hash digest in a coin, I do\nthink it's a very minimal extension of the bitcoin script capabilities. There are margin of discussions\nto discuss what transaction fields should be committed in the template and the hash algorithm performance,\nthough overall it's making clear technical choices.\n\nHistorically, my concern on CTV have been of 2 kind:\n- - it didnt do enough to do the what I'm interested in in terms of off-chain protocols design\n- - the use-cases presented by CTV have always been a bit of free technical claims with no real review\n\nOn the lack of flexible enough capabilities offered for off-chain protocol designers, I'm not\ngoing to make remake here the whole discussion between Jeremy and myself on the trade-off between\n\"radix-pool\" and \"coinpool\" and the implications on how you design a consensus primitive in consequence.\nSuffice to say, for a group of counterparties who which to leave and exit in any order, and with\nthe maximum of fault-tolerance and on-chain cost, the design goal is not meet.\n\nOn the use-cases presented by CTV that have always been a bit of free technical claims (e.g congestion\ntree, vaults, LN ball, DLC ctv), in the lack for every use-cases allegued to be enabled by CTV of\ntransactions + scripts, I do think it has always been hard to evaluate (1) if their _works_ as expected\nand (2) how they score on many dimensions (attacks & risks, economic engineering, privacy, implementation\ncomplexity, protocol unknowns, evolvability, ecosystem impacts, etc).\n\nNow, since 2022, we have more \"toy\" implementations of CTV uses-cases with vaults and the Ark thing\nexperimenting with CTV, and while I'm not personally excited or interested by CTV use-cases I can\nunderstand from the perspective of a off-chain protocol designer how creating immutable vertices\nin your graph of transactions can be very valuable. Immutable in the sense of it's used in BIP112,\nthat you cannot forge it, in the absence of chain reorgs.\n\nOf course, there are trade-off with CTV-based vault approach versus signature-based vault approaches\ndesign. The hash approach with CTV is more footgunish (you have a fee estimation miscomputation for\nthe nAmount, and boom! your funds might be forever frozen). The key approach is more flexible, and\nwhile you can do \"key delete\" in software only, it does not offer the same security guarantees from\nthe perspective of anyone who has spent enough time with a motherboard and a soldering iron.\n\nIn my humble opinion, it's okay to offer different bitcoin scripts ways to design and develop\na use-cases, after all off-chain protocol designers and developers have to sweat a bit too --\nas long as the primitive is safe in itself from the network of full nodes and the stability of\nbitcoin mining.\n\nAbout the unknown knowns of CHECKTEMPLATEVERIFY, I can think of 3 of them, 1) is all the denial-of-service\nrisks of the hashing algorithm for the template risk, 2) is security risk like block signature overflow\nattacks due to misinteraction with other mechanism of the consensus engine and 3) all TxWithold attacks\nor EHHMEEEE_VEEEEE (phonetic) in layman's terms. About TxWithold attacks, and the accidental enabling\nof more powerful off-chain protocol that could leveraged to break base-layer mechanisms (e.g miner bribing\n\"tx-withold\" smart contract to censor lightning txn, it's a _serious_ concern, but so far I have not\nfound with CTV only how you can do that. Door is opened if someone can outsmart on that.\n\nI'm deliberately not going to prononunce myself on the comparative design of CHECKTEMPLATEVERIFY,\nlike TEMPLATEHASH (?) and other primitives. We should remind that CTV was deliberately design to\nthe most _restrictive_ design, after few rounds of interactions (i.e OP_CHECKOUTPUTHASHVERIFY,\nOP_SECURETHEBAG, etc).\n\nMore flexible designs come with more surface of unforeseen interactions, and *sadly* I only realize\nlast year that Block Signature Overflow Attack were a thing that can affect time-sensitive off-chain\nprotocols. So being conservative in the design is a very good thing to be mindful of.\n\nI would support a change of CTV to be Taproot only, but I also understand the concern of the champions\nwith the realities of the bitcoin ecosystem, where most of the coins spents are Segwit V0.\n\nThat's all -- I think I forgot nothing, but if so I'll correct myself.\n\nI do make mine all the concerns of the usual Bitcoin core hackers, that's it's better to very\nvery very very conservative with consensus code changes and more unit, functional, manual testing\nand fuzzing is welcome for this code branch.\n\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n\n_Disclaimer: I'm not paid and I'm not interested to receive any compensation for the time spent on_\n_reviewing consensus changes, be it startup equity, open source grant, ETF paper bitcoin, bitcoin_\n_treasury equity, NFT, shitcoin or anything else. This is including any kind of promise being made_\n_to me of a compensation in any kind of \"forward-looking\" statement._\n\n_All my professional commitments are under bulletproofs legal provisions to let me be free of whatever_\n_I wish to say about bitcoin consensus changes and stay free of potential conflict of interests, with_\n_only my own consciousness and sense of ethics to speak on such a technical subject._\n\n_In Q4 2021, around the Thursday 2 December to be more exact, we were approached with Gleb Naumenko_\n_by Jeremy Rubin for a security review of CTV for a sum around $20k to $30k and we immediately, politely_\n_and gently decline his proposal for ethical reasons._\n\n_I'm an investor in bitcoin, the self-custodied asset._\n-----BEGIN PGP SIGNATURE-----\n\niQIzBAEBCAAdFiEEpaaGjXqpHdAKwaZ/gX/6Ao72HJQFAmirlRgACgkQgX/6Ao72\nHJTxOg/7BRSd4sRrDijpardDWjRDT8tfVNoTLmcgnS73IiPwg2W8qzeov1ylsKjA\nBUZggzvxb5bxZosMHyXksYtL2/YN2xHEuhLI+A41B4zQ2ouRv2fLh8ZZP9sA08Vv\nKniGAKb8+hT6LhG2xR2J+R+Y/Ee/QteGmcnDDK69ukEHnJZOpRKusV7y0AwM4K8W\nPAY9PJ/c4Vpr3Pqp20xmSO37WSZUAuiRYRkmvv1vIYedfWKcP3/is42X41jfu3Vg\nNFqVySpewc7rdfsbvQwfspVKR8h1jnOBcFP3FeRNtjxEq7scfB+Njw0WXBcS0kpL\nCZ4xyitxykigCjuLeRy2Aa+YExykHT7JCD8yqjYB5hO9umjXkpBKJcyX8SgCfuJ6\npmtg451aALW167AtaBPN/a3BQ/ZSm2jfc4VtxPdvcI525d+KcCWgcAzBJeBz57In\n9HsYeYyeDOCgODVUstMQF/Eduxa8uOHotOPHbyWHRGUCNTRPr0MclU69kEyYrq6j\nlVL2h1n65wPShp3m18IQrh0I64RsYzY5bC4cHoSR5O8vqFjGagOqsTdWGUGaq8o0\nwi/9UESSi+G8dsAC5yE2QpeX4y3mSWA98FOSTghIRdcN/SwS7zyYZYOmzJcFHVx8\n773QMDN9ladDUM/t2dc1N3fMQSVxrPbEGp1/tRFosZSTPIXf8Eg=\n=W15h\n-----END PGP SIGNATURE-----" } ], "labels_log": [ { "t": "2025-03-04T19:26:04Z", "action": "labeled", "label": "Consensus", "who": "glozow" }, { "t": "2025-03-25T02:08:31Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-03-26T18:04:06Z", "action": "unlabeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-04-15T16:27:08Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-04-15T19:29:46Z", "action": "unlabeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-04-29T23:01:11Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2025-05-01T00:34:47Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2025-05-07T14:23:07Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2025-05-12T16:42:01Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2025-06-10T12:56:29Z", "action": "labeled", "label": "Needs Conceptual Review", "who": "glozow" }, { "t": "2025-06-15T00:15:00Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-07-01T18:47:13Z", "action": "unlabeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-07-23T15:32:28Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-09-26T11:49:24Z", "action": "unlabeled", "label": "CI failed", "who": "maflcko" }, { "t": "2025-10-08T00:17:58Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" } ], "state_log": [ { "t": "2025-03-05T01:49:37Z", "kind": "renamed", "who": "jamesob", "from": "Add BIP-119 (OP_CHECKTEMPLATEVERIFY) (no activation)", "to": "BIP-119 (OP_CHECKTEMPLATEVERIFY) (no activation)" }, { "t": "2025-03-19T20:27:56Z", "kind": "renamed", "who": "jamesob", "from": "BIP-119 (OP_CHECKTEMPLATEVERIFY) (no activation)", "to": "BIP-119 (OP_CHECKTEMPLATEVERIFY) (regtest only)" } ], "text_chars": 35712, "text_tokens_estimate": 8928, "changed_paths": [ "src/addresstype.cpp", "src/consensus/params.h", "src/deploymentinfo.cpp", "src/kernel/chainparams.cpp", "src/policy/policy.cpp", "src/policy/policy.h", "src/rpc/blockchain.cpp", "src/rpc/rawtransaction.cpp", "src/script/interpreter.cpp", "src/script/interpreter.h", "src/script/script.cpp", "src/script/script.h", "src/script/script_error.cpp", "src/script/script_error.h", "src/script/sign.cpp", "src/script/solver.cpp", "src/script/solver.h", "src/test/CMakeLists.txt", "src/test/ctvhash_tests.cpp", "src/test/data/ctvhash.json", "src/test/data/script_tests.json", "src/test/data/tx_invalid.json", "src/test/data/tx_valid.json", "src/test/fuzz/script.cpp", "src/test/transaction_tests.cpp", "src/test/versionbits_tests.cpp", "src/validation.cpp", "src/wallet/scriptpubkeyman.cpp", "test/functional/feature_checktemplateverify.py", "test/functional/rpc_blockchain.py", "test/functional/test_framework/messages.py", "test/functional/test_framework/script.py", "test/functional/test_runner.py" ], "files": [ { "path": "src/addresstype.cpp", "add": 1, "del": 0 }, { "path": "src/consensus/params.h", "add": 1, "del": 0 }, { "path": "src/deploymentinfo.cpp", "add": 4, "del": 0 }, { "path": "src/kernel/chainparams.cpp", "add": 5, "del": 0 }, { "path": "src/policy/policy.cpp", "add": 5, "del": 0 }, { "path": "src/policy/policy.h", "add": 3, "del": 1 }, { "path": "src/rpc/blockchain.cpp", "add": 4, "del": 0 }, { "path": "src/rpc/rawtransaction.cpp", "add": 4, "del": 0 }, { "path": "src/script/interpreter.cpp", "add": 134, "del": 7 }, { "path": "src/script/interpreter.h", "add": 43, "del": 4 }, { "path": "src/script/script.cpp", "add": 9, "del": 1 }, { "path": "src/script/script.h", "add": 4, "del": 1 }, { "path": "src/script/script_error.cpp", "add": 2, "del": 0 }, { "path": "src/script/script_error.h", "add": 1, "del": 0 }, { "path": "src/script/sign.cpp", "add": 1, "del": 0 }, { "path": "src/script/solver.cpp", "add": 5, "del": 0 }, { "path": "src/script/solver.h", "add": 1, "del": 0 }, { "path": "src/test/CMakeLists.txt", "add": 2, "del": 0 }, { "path": "src/test/ctvhash_tests.cpp", "add": 203, "del": 0 }, { "path": "src/test/data/ctvhash.json", "add": 2204, "del": 0 }, { "path": "src/test/data/script_tests.json", "add": 5, "del": 6 }, { "path": "src/test/data/tx_invalid.json", "add": 95, "del": 0 }, { "path": "src/test/data/tx_valid.json", "add": 152, "del": 0 }, { "path": "src/test/fuzz/script.cpp", "add": 1, "del": 0 }, { "path": "src/test/transaction_tests.cpp", "add": 3, "del": 0 }, { "path": "src/test/versionbits_tests.cpp", "add": 6, "del": 0 }, { "path": "src/validation.cpp", "add": 12, "del": 1 }, { "path": "src/wallet/scriptpubkeyman.cpp", "add": 5, "del": 0 }, { "path": "test/functional/feature_checktemplateverify.py", "add": 738, "del": 0 }, { "path": "test/functional/rpc_blockchain.py", "add": 13, "del": 0 }, { "path": "test/functional/test_framework/messages.py", "add": 14, "del": 0 }, { "path": "test/functional/test_framework/script.py", "add": 2, "del": 2 }, { "path": "test/functional/test_runner.py", "add": 1, "del": 0 } ], "test_lines": 3447, "git": { "head": "18d71b65dbce8231cca10659c0e0c0dcc73e6bdf", "head_matches_backup": true, "base": "b1821d8dd39f2450ad22b614bae7b1fb28c1ec97", "commits": [ { "sha": "0cf7d5c65a", "subject": "Add StandardTemplateHash definition", "files": 2, "add": 91, "del": 0 }, { "sha": "22549571de", "subject": "Add OP_CHECKTEMPLATEVERIFY Opcode as OP_NOP4", "files": 7, "add": 66, "del": 15 }, { "sha": "c22e734693", "subject": "script: precompute the DefaultCheckTemplateVerifyHash", "files": 2, "add": 40, "del": 13 }, { "sha": "1ddb4bf3c3", "subject": "policy: make bare OP_CHECKTEMPLATEVERIFY standard", "files": 12, "add": 40, "del": 1 }, { "sha": "d51d32c637", "subject": "test: add tx_valid.json tests for BIP-119 CheckTemplateVerify", "files": 1, "add": 152, "del": 0 }, { "sha": "e657a1c48b", "subject": "test: add tx_invalid.json examples for CTV", "files": 1, "add": 95, "del": 0 }, { "sha": "21742d65b0", "subject": "test: add CTV hash computation unit test & mutation tester", "files": 3, "add": 2409, "del": 0 }, { "sha": "ef21f31671", "subject": "consensus: add a CTV deployment for regtest only", "files": 8, "add": 46, "del": 3 }, { "sha": "18d71b65db", "subject": "test: add OP_CHECKTEMPLATEVERIFY functional tests", "files": 4, "add": 755, "del": 2 } ], "patch_truncated": true }, "input_hash": "d5a3ab17c880223c", "extracted_at": "2026-09-17T16:15:31+00:00" }