Skip to content

Implement regtest-only BIP448#1

Open
instagibbs wants to merge 12 commits into
bip448:masterfrom
instagibbs:2026-06-bip448
Open

Implement regtest-only BIP448#1
instagibbs wants to merge 12 commits into
bip448:masterfrom
instagibbs:2026-06-bip448

Conversation

@instagibbs

Copy link
Copy Markdown

Based on master branch

darosior and others added 12 commits June 18, 2026 12:56
The deployment is never active on mainnet or testnet. Activation parameters are intentionally left
to be defined eventually and out of scope for this patchset.

The deployment is always active on regtest, allowing us to extensively test expected behaviour of
the proposed operation using the functional test suite.

Co-Authored-By: Greg Sanders <gsanders87@gmail.com>
Script validation of OP_TEMPLATEHASH is enabled past
its activation height, which means it is currently never
enabled on mainnet/testnet and always is on regtest.

Tapscript spends making use of OP_TEMPLATEHASH do not get
relayed nor included in blocks until the soft fork is
active. We no longer disconnect or ban for loose mempool
transaction failures, so we can add the new flag directly to
mandatory flag set, which makes disconnect and bans possible
in blocks only post-activation.

Co-Authored-by: Greg Sanders <gsanders87@gmail.com>
This introduces a new Script operation exclusively available in Tapscript context: OP_TEMPLATEHASH.
This operation pushes the hash of the spending transaction on the stack. See BIP446 for details.

This operation is introduced as replacing OP_SUCCESS206 (0xce).

Co-Authored-By: Greg Sanders <gsanders87@gmail.com>
Sanity check the template hash by using it to commit to the transaction that must spend an output.
Malleating committed fields must lead to a consensus failure, and changing non-committed fields is
fine.

We also add the option to generate test vectors from this unit test.
We introduce one specialized target focused on exercising the new `GetTemplateHash()` logic
introduced for OP_TEMPLATEHASH, and one broader fuzz target which exercises using OP_TEMPLATEHASH
on a variety of transactions while asserting invariants.
This leverages the extensive feature_taproot.py test framework to generate coverage for the numerous
scenarii and mutations exercised there.

Additionally, a separate feature_templatehash.py functional test is introduced for end-to-end
testing of the commit-to-next-transaction use case, which does not fit nicely into the
feature_taproot.py framework (assumes input independence).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants