BIP 0342
What changes when Bitcoin runs a Taproot script?
Taproot decides which script may run. Tapscript decides what running it means: new signature opcodes, a budget instead of a count, and opcodes held in reserve for the future.
The previous chapter ended at a door. A script path spend proves that the output committed to a particular script, and then the script has to run. BIP 341 deliberately says little about how. That is BIP 342’s job.12
BIP 342, assigned in 2020 and deployed together with BIP 341, specifies the first scripting system for Taproot, called tapscript. Its authors explain why it could not wait: Taproot’s goals, Schnorr signatures, batch validation and a better signature hash, clash with how some existing opcodes behave, so the script language had to change at the same time.134
Source details
This chapter is an independent explanation, not the proposals themselves. Preamble fields are shown as recorded in the pinned files, with author e-mail addresses omitted. Status is the proposal’s own field, not an endorsement or a sign of consensus.
BIP 342: Validation of Taproot Scripts
- BIP
- 342
- Layer
- Consensus (soft fork)
- Title
- Validation of Taproot Scripts
- Authors
- Pieter Wuille
Jonas Nick
Anthony Towns - Status
- Deployed
- Type
- Specification
- Assigned
- 2020-01-19
- License
- BSD-3-Clause
- Requires
- 340, 341
- item 0 · initial stackempty
(empty) - item 1 · initial stack64-byte signature
1cecfe0d…f5d0 - item 2 · script · 71 B with prefix
<32-byte push> OP_CHECKSIGVERIFY OP_0 <32-byte push> OP_CHECKSIGADD OP_NOT - item 3 · control block · 548 B with prefixcontrol byte (leaf version 0xc0), internal key, 16 sibling hashes
BIP 341 uses the last two items: it checks that the output key commits to this script and its leaf version (Fig. A07.2).
BIP 342 applies because the leaf version is 0xc0: it runs the script, starting from the items before it as the stack.
Bitcoin Core qa-assets script_assets_test.json, case 1135 (“tapscript/emptysigs/checksigadd”), success witness.
Structure first, then execution
BIP 342 applies only in one situation: a version 1, 32-byte Taproot output, spent by its script path, with leaf version 0xc0. Spends with other leaf versions simply succeed under BIP 341, leaving them for future rules. The checks happen in a fixed order. First, anything BIP 141 or BIP 341 rejects is rejected. Then the script is decoded, the starting stack is checked against resource limits, the script runs, and it must finish with exactly one element on the stack, and that element must be true.25
The execution rules themselves start from those of P2WSH, SegWit version 0’s script spends, and change a short list of things. The rest of this chapter walks through that list.7
Signature opcodes, rewritten
OP_CHECKSIG and OP_CHECKSIGVERIFY now take 32-byte keys and check BIP 340 Schnorr signatures. What gets signed is BIP 341’s signature message with a tapscript extension: the hash of the leaf being run, a key version byte and the position of the last executed OP_CODESEPARATOR. The signature therefore names the script it authorizes, through the leaf hash, instead of a copy of the script code.89
The opcodes pop a public key and a signature, and the BIP spells out each case; the failure cases use MUST. Too few stack elements, or an empty public key, make the script fail immediately. A 32-byte key with a non-empty signature means a real BIP 340 check, and a failed check ends the script at once rather than pushing false.1011
An empty signature is the polite way to decline. It is never checked. OP_CHECKSIG pushes an empty vector, meaning false, and carries on; OP_CHECKSIGVERIFY fails. A key of any other non-zero length is an unknown key type: no verification happens and a non-empty signature simply counts as success. That sounds alarming; the authors explain that the slot exists so that a future soft fork can add new kinds of keys and signature rules.1213
No more CHECKMULTISIG
Tapscript disables OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. Run one, and the script fails on the spot, exactly as OP_RETURN would; in a branch that is not taken it is ignored. The authors chose an outright failure so that anyone still writing the old opcode notices immediately.14
Its replacement is OP_CHECKSIGADD. It pops a key, a number n and a signature; a valid signature pushes n + 1 and an empty one pushes n unchanged. The authors note that the old multisignature opcodes cannot be batch verified, and that the new one does the work of four existing opcodes in one byte. Their suggested rewrite of a k-of-n policy is a chain: check the first key with OP_CHECKSIG, add each further key with OP_CHECKSIGADD, and compare the total with k. Each signer’s slot in the witness holds either a signature or an empty vector.1215161718
That is not the only design. They also describe putting each k-of-k combination in its own leaf, aggregating each combination into one key, or using threshold signatures, each trading privacy, cost and interaction differently.19
The figure below replays six spends from Bitcoin Core’s validation tests, each with a witness Core accepts and one it rejects. Step through them opcode by opcode. In one, a valid signature turns 23 into 24 and the script compares the result; in its failing twin, n is five bytes long, and the BIP says that MUST fail. Another hands OP_CHECKSIGADD an empty signature and pays nothing for it, while its failure witness offers an empty key instead.62021
A · Interactive
Recorded, verified example · not a general interpreter
Static view: the success witness of the first scenario, played to the end. With JavaScript you can step through each of the 6 scenarios, compare the success and failure witnesses, and watch the signature budget.
<32-byte push>OP_CHECKSIGVERIFYOP_0<32-byte push>OP_CHECKSIGADDOP_NOT
Result
✓ valid exactly one true element remains. Bitcoin Core labels this witness valid; the recording agrees.
- number 1
01
Signature checks
Budget = 50 + 686 witness bytes = 736
OP_CHECKSIGVERIFY· 32-byte key · valid BIP 340 signature → budget 686OP_CHECKSIGADD· 32-byte key · empty signature: not checked, not counted → budget 686
Remaining: 686 · non-empty signatures counted: 1
Witness: 686 bytes serialized = 1 (item count) + initial stack 66 + script 71 + control block 548, each part with its length prefix. The control block was checked against the output key, as in Fig. A07.2.
Exact values
- script
209847ef0ad775f9346edae702efe32dc8eaac2bc3a8482f0ecdce80d5b0925316ad00201aa6528fd172599ed6f26cb8805585a15351223e227553b7d801c6d1e35f0709ba91- 64-byte signature
1cecfe0d8b353338f9dedfa5c45db0772cf198993d57e2319259269d205ba8a088be60cf39fcc2c59ea87e4ab7ca064d867de18fa7d1f50ddd5d4e5690cdf5d0- 32-byte key
9847ef0ad775f9346edae702efe32dc8eaac2bc3a8482f0ecdce80d5b0925316- 32-byte key
1aa6528fd172599ed6f26cb8805585a15351223e227553b7d801c6d1e35f0709
Source: Bitcoin Core qa-assets script_assets_test.json, case 1135 (“tapscript/emptysigs/checksigadd”), pinned by commit; linked from BIP 341’s test-vector section. Signature checks use the BIP 341 signature message with the BIP 342 extension.
B · Worked example
Bitcoin Core test case 1109 (CHECKSIGADD counts), success witness: the starting stack, then one opcode per layer. Cells are stack elements.
Start from the witness, minus the script and control block
- stack, top first
64-byte signature
Sigops budget: 50 + 654 witness bytes = 704; each checked signature costs 50.
<1-byte push>
- stack, top first
number 23 / 64-byte signature
push 1 byte
<32-byte push>
- stack, top first
32-byte key / number 23 / 64-byte signature
push 32 bytes
OP_CHECKSIGADD
- stack, top first
number 24
signature valid: push n + 1 = 24; budget now 654
<1-byte push>
- stack, top first
number 24 / number 24
push 1 byte
OP_EQUAL
- stack, top first
number 1
byte-for-byte equal: push 1
Source: Core script_assets_test.json case 1109, pinned; recorded at build time and matched to Core’s label.
The CHECKMULTISIG case shows the change most plainly. Its success witness runs a one-key OP_CHECKSIG. Its failure witness tries the same 1-of-1 policy with OP_CHECKMULTISIG, which fails the moment it executes, before any signature is looked at.1422
A budget instead of a count
Older scripts count signature operations against a limit for the whole block. Tapscript signature operations are left out of that count. Instead each input gets its own budget: 50 plus the size of its witness in bytes. Every signature opcode run with a non-empty signature subtracts 50, and if the budget drops below zero the script fails. The authors’ reason is practical: a second block-wide limit, alongside weight, made it harder to choose transactions for a block.2627
The effect is that signatures are paid for in witness bytes. A signature checked against a 32-byte key must be 64 or 65 bytes, and with its length prefix it raises the budget by more than the 50 its check costs. Empty signatures are free. Unknown key types are not: they skip verification but are still charged, whatever the signature’s length.13242628
- Empty signatures with CHECKSIGADD50 + 686 = 736 · 1 × 50 spent · 686 left
- CHECKSIGADD counts50 + 654 = 704 · 1 × 50 spent · 654 left
- CHECKSIG vs CHECKMULTISIG50 + 649 = 699 · 1 × 50 spent · 649 left
- An unknown key type50 + 650 = 700 · 1 × 50 spent · 650 left
- IF needs exactly 0 or 150 + 655 = 705 · 1 × 50 spent · 655 left
- OP_SUCCESS50 + 133 = 183 · 0 × 50 spent · 183 left
spent by non-empty signaturesremaining budget
Success witnesses of the recorded Core test cases. Witness sizes are serialized sizes: the item count plus every item with its length prefix. The OP_SUCCESS spend never reaches the budget: it is valid before any opcode runs.
Other limits move too. The 10,000-byte script size limit and the 201 non-push opcode limit do not apply to tapscript. The limit of 1,000 stack elements remains and now also covers the starting stack taken from the witness, and elements still may not exceed 520 bytes.29
Room to grow, and a rule made strict
Some opcode numbers are reserved as OP_SUCCESSx. Once the BIP 141 and BIP 341 checks have passed, if the decoder meets one of these opcodes anywhere in the script, the spend is valid at once, before the remaining tapscript rules, even if bytes after it would not decode. In the recorded case the whole script is opcode 126, OP_SUCCESS126, and nothing runs. The authors present this as an upgrade mechanism: a later soft fork can give such an opcode a meaning, which only ever makes fewer spends valid. In a footnote they also warn that using one before it is defined is insecure and leads to fund loss.253031
One rule went the other way, from advice to consensus. In P2WSH, MINIMALIF is only a standardness rule; in tapscript, OP_IF and OP_NOTIF must receive exactly an empty vector or the single byte 0x01. In the recorded MINIMALIF case, the failing witness offers a three-byte value instead, and the script stops at OP_IF.2332
Where these traces come from
BIP 342 says that BIP 341’s test vectors contain tapscript examples. The wallet vector file pinned for this site contains tapscript leaves but no script path spends, so there is nothing there to execute. BIP 341 also links Bitcoin Core’s validation test vectors, on the main branch of Core’s test-asset repository; this site chose one commit of that file, and this chapter uses six cases from it, copied and checked by hash.3334
Two of the cases are upgrade hooks: an OP_SUCCESS opcode and an unknown key type. Core’s tests show what consensus accepts, not what is safe; the BIP warns against using OP_SUCCESS opcodes before a soft fork defines them, and unknown key types exist only so that one can.13242531
Each recorded run was checked twice at build time: the control block against the output key, as in the previous chapter, and the final verdict against Core’s label. If either check had disagreed, this page would not have been built.6
Evidence
Each numbered marker in the text points here, and the ↩ links lead back to every place that cites an entry. Quotes are verbatim from the BIP files at commit
3a10b5b, including their wiki markup; links open
the exact lines; the quoted text sits under each entry. Labels say what kind of statement each is: a rule, the author’s rationale, history,
a test vector, or our own inference.
-
↩ a b Rule BIP 342 specifies the semantics of the initial scripting system under BIP 341.
Quoted source text (1)
This document specifies the semantics of the initial scripting system under [[bip-0341.mediawiki|BIP341]].
-
↩ a b c Rule The rules apply only to a witness version 1, 32-byte, non-P2SH Taproot script path spend whose leaf version is 0xc0; under BIP 341, spends with other leaf versions succeed, leaving them for future rules.
Quoted source text (2)
This implies that for the future leaf versions (non-''0xC0'') the execution must succeed.
It is a '''taproot spend''' as defined in [[bip-0341.mediawiki#design|BIP341]] (i.e., the witness version is 1, the witness program is 32 bytes, and it is not P2SH wrapped). * It is a '''script path spend''' as defined in [[bip-0341.mediawiki#design|BIP341]] (i.e., after removing the optional annex from the witness stack, two or more stack elements remain). * The leaf version is ''0xc0''
-
↩ History BIP 342 is a consensus soft-fork proposal assigned in 2020; its preamble records the status Deployed and that it requires BIPs 340 and 341, and it is deployed identically to BIP 341.
BIP 342 L3 BIP 342 L8 BIP 342 L10 BIP 342 L13 BIP 342 L140
Quoted source text (5)
Layer: Consensus (soft fork)
Status: Deployed
Assigned: 2020-01-19
Requires: 340, 341
This proposal is deployed identically to Taproot ([[bip-0341.mediawiki|BIP341]]).
-
↩ Author’s rationale The authors write that BIP 341 changes only the script structure, while some of its goals conflict with how certain opcodes behave, so Schnorr signatures, batch validation and the new signature hash had to reach script spends as well.
BIP 342 L28 BIP 342 L29 BIP 342 L31
Quoted source text (3)
proposes improvements to just the script structure, but some of its goals are incompatible with the semantics of certain opcodes within the scripting language itself.
their impact is not guaranteed unless they are addressed simultaneously with [[bip-0341.mediawiki|BIP341]] itself.
Specifically, the goal is making '''Schnorr signatures''', '''batch validation''', and '''signature hash''' improvements available to spends that use the script system as well.
-
↩ a b Rule Validation must be equivalent to these steps in order: fail if BIP 141 or BIP 341 fails; decode the tapscript; check the initial stack's resource limits; execute; and require exactly one true element at the end.
BIP 342 L54–55 BIP 342 L63 BIP 342 L66
Quoted source text (3)
Validation of such inputs must be equivalent to performing the following steps in the specified order. # If the input is invalid due to BIP141 or BIP341, fail.
If the '''initial stack''' as defined in BIP341 (i.e., the witness stack after removing both the optional annex and the two last stack elements after that) violates any resource limits
If the execution results in anything but exactly one element on the stack which evaluates to true with <code>CastToBool()</code>, fail.
-
↩ a b c d e f Test vector For each of the six recorded Core cases, the recorder's verdict on both the success and the failure witness matches Core's label, and every control block passes the BIP 341 commitment check; the recorder refuses any opcode outside its reviewed set rather than guessing.
Quoted source text (1)
Validation of such inputs must be equivalent to performing the following steps in the specified order.
-
↩ Rule Tapscript execution follows the P2WSH rules of BIP 141 with a list of modifications.
Quoted source text (2)
The execution rules for tapscript are based on those for P2WSH according to BIP141
but with the following modifications:
-
↩ Rule OP_CHECKSIG and OP_CHECKSIGVERIFY verify BIP 340 Schnorr signatures, over a signature message based on BIP 341's.
Quoted source text (1)
signature opcodes <code>OP_CHECKSIG</code> and <code>OP_CHECKSIGVERIFY</code> are modified to verify Schnorr signatures as specified in [[bip-0340.mediawiki|BIP340]] and to use a signature message algorithm based on the common message calculation in [[bip-0341.mediawiki|BIP341]].
-
↩ Rule A tapscript signature signs hash_TapSighash(0x00 || SigMsg(hash_type, 1) || ext), where ext adds the tapleaf hash, a key version 0x00 and the position of the last executed OP_CODESEPARATOR; it commits to the executed script through the tapleaf hash rather than a scriptCode.
BIP 342 L116 BIP 342 L108–110 BIP 342 L122
Quoted source text (3)
If the ''sig'' is 64 bytes long, return ''Verify(p, hash<sub>TapSighash</sub>(0x00 || SigMsg(0x00, 1) || ext), sig)''
''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki#design|BIP341]] * ''key_version'' (1): a constant value ''0x00'' representing the current version of public keys in the tapscript signature opcode execution. * ''codesep_pos'' (4): the opcode position of the last executed <code>OP_CODESEPARATOR</code>
The signature message commits to the executed script through the ''tapleaf_hash'' which includes the leaf version and script instead of ''scriptCode''.
-
↩ Rule CHECKSIG and CHECKSIGVERIFY pop a public key and a signature; CHECKSIGADD also pops a number n between them. Too few elements, an n longer than 4 bytes, or an empty public key MUST make the script fail immediately.
Quoted source text (1)
For <code>OP_CHECKSIGVERIFY</code> and <code>OP_CHECKSIG</code>, the public key (top element) and a signature (second to top element) are popped from the stack. ** If fewer than 2 elements are on the stack, the script MUST fail and terminate immediately. * For <code>OP_CHECKSIGADD</code>, the public key (top element), a <code>CScriptNum</code> <code>n</code> (second to top element), and a signature (third to top element) are popped from the stack. ** If fewer than 3 elements are on the stack, the script MUST fail and terminate immediately. ** If <code>n</code> is larger than 4 bytes, the script MUST fail and terminate immediately. * If the public key size is zero, the script MUST fail and terminate immediately.
-
↩ Rule With a 32-byte key, a non-empty signature is checked as a BIP 340 signature, and a failed check ends the script with failure.
Quoted source text (1)
If the public key size is 32 bytes, it is considered to be a public key as described in BIP340: ** If the signature is not the empty vector, the signature is validated against the public key (see the next subsection). Validation failure in this case immediately terminates script execution with failure.
-
↩ a b Rule An empty signature is not checked: CHECKSIGVERIFY MUST fail, CHECKSIG pushes an empty vector, and CHECKSIGADD pushes n unchanged.
Quoted source text (1)
If the signature is the empty vector: *** For <code>OP_CHECKSIGVERIFY</code>, the script MUST fail and terminate immediately. *** For <code>OP_CHECKSIG</code>, an empty vector is pushed onto the stack, and execution continues with the next opcode. *** For <code>OP_CHECKSIGADD</code>, a <code>CScriptNum</code> with value <code>n</code> is pushed onto the stack, and execution continues with the next opcode.
-
↩ a b c Rule A public key that is neither empty nor 32 bytes is an unknown key type: no signature check is applied and a non-empty signature counts as successful, leaving room for soft forks to add new signature rules.
BIP 342 L94 BIP 342 L94 BIP 342 L94
Quoted source text (3)
If the public key size is not zero and not 32 bytes, the public key is of an ''unknown public key type''
and no actual signature verification is applied. During script execution of signature opcodes they behave exactly as known public key types except that signature validation is considered to be successful.
allow adding new signature validation rules through softforks.
-
↩ a b Rule OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are disabled: like OP_RETURN, they fail the script immediately when executed and are ignored in unexecuted branches. The authors chose this so that anyone who keeps using them notices immediately.
Quoted source text (2)
The disabled opcodes behave in the same way as <code>OP_RETURN</code>, by failing and terminating the script immediately when executed, and being ignored when found in unexecuted branch of the script.
This is a precaution to make sure people who accidentally keep using <code>OP_CHECKMULTISIG</code> in Tapscript notice a problem immediately.
-
↩ Rule Opcode 186 is OP_CHECKSIGADD, a new signature opcode added by BIP 342.
Quoted source text (2)
The opcode 186 (<code>0xba</code>) is named as <code>OP_CHECKSIGADD</code>.
and a new opcode <code>OP_CHECKSIGADD</code> is added.
-
↩ Author’s rationale In a rationale footnote, the authors say OP_CHECKSIGADD compensates for CHECKMULTISIG-like opcodes, which are incompatible with batch verification, and that it is equivalent to OP_ROT OP_SWAP OP_CHECKSIG OP_ADD in one byte.
Quoted source text (1)
This opcode is added to compensate for the loss of <code>OP_CHECKMULTISIG</code>-like opcodes, which are incompatible with batch verification. <code>OP_CHECKSIGADD</code> is functionally equivalent to <code>OP_ROT OP_SWAP OP_CHECKSIG OP_ADD</code>, but only takes 1 byte.
-
↩ Rule A non-empty signature counts toward the sigops budget; then CHECKSIGVERIFY continues, CHECKSIG pushes 0x01, and CHECKSIGADD pushes n + 1.
Quoted source text (1)
If the signature is not the empty vector, the opcode is counted towards the sigops budget (see further). *** For <code>OP_CHECKSIGVERIFY</code>, execution continues without any further changes to the stack. *** For <code>OP_CHECKSIG</code>, a 1-byte value <code>0x01</code> is pushed onto the stack. *** For <code>OP_CHECKSIGADD</code>, a <code>CScriptNum</code> with value of <code>n + 1</code> is pushed onto the stack.
-
↩ Author’s rationale In a rationale footnote, the authors show that a CHECKMULTISIG policy can be rewritten as <pubkey_1> CHECKSIG <pubkey_2> CHECKSIGADD … m NUMEQUAL, with one witness element per key that is either a signature or empty.
Quoted source text (1)
can be rewritten as script <code><pubkey_1> CHECKSIG <pubkey_2> CHECKSIGADD ... <pubkey_n> CHECKSIGADD m NUMEQUAL</code> with witness <code><w_n> ... <w_1></code>. Every witness element <code>w_i</code> is either a signature corresponding to <code>pubkey_i</code> or an empty vector.
-
↩ Author’s rationale The authors list other ways to express k-of-n: a k-of-k script per combination in separate leaves, an aggregated key per combination, or native threshold signatures, each with trade-offs.
BIP 342 L78 BIP 342 L79 BIP 342 L80
Quoted source text (3)
A ''k''-of-''n'' policy can be implemented by splitting the script into several leaves of the Merkle tree, each implementing a ''k''-of-''k'' policy
This approach is far more efficient, but does require a 3-round interactive signing protocol to jointly produce the (single) signature.
Multisig policies can also be realized with [http://cacr.uwaterloo.ca/techreports/2001/corr2001-13.ps threshold signatures] using verifiable secret sharing.
-
↩ a b Test vector In Core case 1109, CHECKSIGADD with n = 23 and a valid signature leaves 24, which equals the pushed 24; the failure witness's 5-byte n stops the script.
Quoted source text (2)
If <code>n</code> is larger than 4 bytes, the script MUST fail and terminate immediately.
For <code>OP_CHECKSIGADD</code>, a <code>CScriptNum</code> with value of <code>n + 1</code> is pushed onto the stack.
-
↩ a b Test vector In Core case 1135 the script checks one signature with CHECKSIGVERIFY and gives CHECKSIGADD an empty signature, which leaves n = 0 and costs no budget; the failure witness's script hands CHECKSIGADD an empty public key, which stops it.
Quoted source text (2)
For <code>OP_CHECKSIGADD</code>, a <code>CScriptNum</code> with value <code>n</code> is pushed onto the stack
If the public key size is zero, the script MUST fail and terminate immediately.
-
↩ a b Test vector In Core case 804 the success witness's script is <key> CHECKSIG; the failure witness tries a 1-of-1 CHECKMULTISIG, which fails as soon as it runs.
Quoted source text (1)
by failing and terminating the script immediately when executed
-
↩ a b Test vector In Core case 662 the success witness gives OP_IF the byte 0x01; the failure witness gives it a 3-byte value, which MINIMALIF rejects.
Quoted source text (1)
must be either exactly 0 (the empty vector) or exactly 1 (the one-byte vector with value 1)
-
↩ a b c Test vector In Core case 824 a 33-byte key makes CHECKSIG skip verification and push 1, while still spending 50 of the budget; the failure witness uses the 32-byte form of the same key, so the signature is checked for real and fails.
Quoted source text (2)
If the public key size is not zero and not 32 bytes, the public key is of an ''unknown public key type''
Signature opcodes with unknown public key type and non-empty signature are also counted.
-
↩ a b c Test vector In Core case 50 the success script is the single opcode 126, an OP_SUCCESSx, so the spend is valid without running anything; the failure script is OP_NOP, which leaves an empty stack and fails.
Quoted source text (2)
## If any opcode numbered ''80, 98, 126-129
If the execution results in anything but exactly one element on the stack which evaluates to true
-
↩ a b c d Rule Tapscript signature operations do not count toward the block-wide sigops limit; instead each input has a budget of 50 plus its serialized witness size, and every signature opcode with a non-empty signature subtracts 50, failing the script if the budget goes below zero. Unknown key types count too.
Quoted source text (1)
The sigops in tapscripts do not count towards the block-wide limit of 80000 (weighted). Instead, there is a per-script sigops ''budget''. The budget equals 50 + the total serialized size in bytes of the transaction input's witness (including the <code>CompactSize</code> prefix). Executing a signature opcode (<code>OP_CHECKSIG</code>, <code>OP_CHECKSIGVERIFY</code>, or <code>OP_CHECKSIGADD</code>) with a non-empty signature decrements the budget by 50. If that brings the budget below zero, the script fails immediately. Signature opcodes with unknown public key type and non-empty signature are also counted.
-
↩ Author’s rationale The authors explain that tying signature operations to witness weight removes a second constraint that made block construction harder.
Quoted source text (1)
The old sigop limit makes transaction selection in block construction unnecessarily difficult because it is a second constraint in addition to weight. Instead, the number of tapscript signature opcodes is limited by witness weight.
-
↩ Editorial inference A signature checked against a 32-byte key must be 64 or 65 bytes, so with its length prefix it adds at least 65 bytes, more than the 50 its check costs; an unknown-key-type signature can be shorter and is still charged 50.
BIP 342 L116–118 BIP 342 L118 BIP 342 L130
Quoted source text (3)
If the ''sig'' is 64 bytes long, return ''Verify(p, hash<sub>TapSighash</sub>(0x00 || SigMsg(0x00, 1) || ext), sig)''
* Otherwise, fail.
Signature opcodes with unknown public key type and non-empty signature are also counted.
-
↩ Rule The 10,000-byte script size limit and the 201 non-push opcode limit do not apply; the 1,000-element stack limit remains and is extended to the initial stack, and the 520-byte element limit remains for the initial stack and pushes.
BIP 342 L128 BIP 342 L129 BIP 342 L131–132
Quoted source text (3)
The maximum script size of 10000 bytes does not apply.
The maximum non-push opcodes limit of 201 per script does not apply.
The existing limit of 1000 elements in the stack and altstack together after every executed opcode remains. It is extended to also apply to the size of initial stack. * '''Stack element size limit''' The existing limit of maximum 520 bytes per stack element remains, both in the initial stack and in push opcodes.
-
↩ Rule After the BIP 141 and BIP 341 checks, any OP_SUCCESSx opcode met while decoding the script makes validation succeed, before the remaining tapscript rules and even if later bytes would not decode; a push that runs past the end fails.
Quoted source text (2)
is encountered, validation succeeds (none of the rules below apply). This is true even if later bytes in the tapscript would fail to decode otherwise.
If any push opcode fails to decode because it would extend past the end of the tapscript, fail.
-
↩ a b Author’s rationale The authors describe OP_SUCCESSx as an upgrade mechanism: a soft fork can give one a meaning, only ever turning valid scripts invalid, and they allow new opcodes more cleanly than OP_NOP. In a rationale footnote they warn that using one before it is defined is insecure and leads to fund loss.
BIP 342 L44 BIP 342 L57 BIP 342 L58 BIP 342 L57
Quoted source text (4)
Additionally, the new tapscript <code>OP_SUCCESS</code> opcodes allow introducing new opcodes more cleanly than through <code>OP_NOP</code>.
is a mechanism to upgrade the Script system.
Any rule changes to an <code>OP_SUCCESSx</code>-containing script may only turn a valid script into an invalid one, and this is always achievable with softforks.
Using an <code>OP_SUCCESSx</code> before its meaning is defined by a softfork is insecure and leads to fund loss.
-
↩ Rule MINIMALIF, only a standardness rule in P2WSH, is consensus in tapscript: OP_IF and OP_NOTIF take exactly the empty vector or the single byte 0x01.
Quoted source text (1)
The MINIMALIF rules, which are only a standardness rule in P2WSH, are consensus enforced in tapscript. This means that the input argument to the <code>OP_IF</code> and <code>OP_NOTIF</code> opcodes must be either exactly 0 (the empty vector) or exactly 1 (the one-byte vector with value 1)
-
↩ Rule BIP 342 says the BIP 341 test vectors also contain tapscript examples; BIP 341 links Bitcoin Core's validation test vectors, used in its unit test framework, on that repository's main branch.
Quoted source text (2)
The Taproot ([[bip-0341.mediawiki|BIP341]]) test vectors also contain examples for Tapscript execution.
Validation test vectors used in the [https://github.com/bitcoin/bitcoin/blob/3820090bd619ac85ab35eff376c03136fe4a9f04/src/test/script_tests.cpp#L1718 Bitcoin Core unit test framework] can be found [https://github.com/bitcoin-core/qa-assets/blob/main/unit_test_data/script_assets_test.json?raw=true here].
-
↩ Editorial inference The wallet vector file in this snapshot holds tapscript leaves but publishes no script path spends, so the traces here come from the Core validation cases BIP 341 links to, pinned at a fixed commit.
Quoted source text (2)
For each of its BIP341 inputs, the internal private key and the Merkle root it was derived from is given, as well as the expected witness to spend it.
Test vectors for wallet operation (scriptPubKey computation, key path spending, control block construction) can be found