<p>As of September 2023, &quot;high-level&quot; script validation with all active consensus rules on the network is approximately this:</p>
<h3>Top level evaluation</h3>
<ul>
<li>Execute the <code>scriptSig</code>, and call the resulting stack <code>stack</code>. If execution aborts, fail.</li>
<li>Execute the <code>scriptPubKey</code> with <code>stack</code> as input, and call the resulting stack <code>result</code>. If execution aborts, fail.</li>
<li>If <code>result</code> is empty, or its top element has numerical value 0, fail.</li>
<li>[from <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">BIP141]</a> If <code>scriptPubKey</code> is exactly equal to an OP_n (with <code>n</code> between 0 and 16, inclusive) followed by a direct push of exactly 2 to 40 bytes inclusive:
<ul>
<li>If <code>scriptSig</code> not empty, fail.</li>
<li>Run segwit validation with the 2-to-40 byte push in <code>scriptPubKey</code> as program, the <code>n</code> value as version, and <code>witness</code> as input (see further). If this execution aborts, fail.</li>
</ul>
</li>
<li>[From <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki" rel="nofollow noreferrer">BIP16]</a> If <code>scriptPubKey</code> is exactly equal to OP_HASH160 + a 20 byte push + OP_EQUAL, run P2SH validation:
<ul>
<li>If <code>scriptSig</code> does not consists of only pushes, fail.</li>
<li>If <code>result</code> is empty, fail.</li>
<li>Interpret the top element of <code>result</code> as a script, and execute it, with the rest of <code>result</code> as input. Call the resulting stack <code>p2sh_result</code>. If this execution aborts, fail.</li>
<li>If <code>p2sh_result</code> is empty, or its top element has numerical value 0, fail.</li>
<li>[From <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">BIP141]</a> If the top element of <code>result</code> is exactly OP_n (with <code>n</code> between 0 and 16 inclusive) followed by a direct push of 2 through 40 bytes inclusive:
<ul>
<li>If <code>scriptSig</code> is not exactly a direct push of the top element of <code>result</code>, fail.</li>
<li>Run segwit validation with the 2-to-40 byte push in the top element of <code>result</code> as program, the <code>n</code> value as version, and <code>witness</code> as input (see further). If this execution aborts, fail.</li>
</ul>
</li>
</ul>
</li>
<li>If segwit validation did <em>not</em> trigger, but a witness is provided in the transaction input, fail.</li>
<li>If no failure occurred before this point, the input is valid.</li>
</ul>
<h3>Segwit validation</h3>
<p>Segwit validation for version <code>version</code>, with program <code>program</code>, and input <code>input</code>:</p>
<ul>
<li>[From <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">BIP141]</a> If the version is 0:
<ul>
<li>If the program is not 20 or 32 bytes, fail.</li>
<li>If the program is 20 bytes <code>hash</code>:
<ul>
<li>If <code>input</code> is not exactly 2 elements, fail.</li>
<li>Execute the script OP_DUP OP_HASH160 <code>hash</code> OP_EQUALVERIFY OP_CHECKSIG, with initial stack <code>input</code>. If execution aborts, fail.</li>
<li>If the resulting stack is not exactly one element, or that element has numerical value 0, fail.</li>
</ul>
</li>
<li>If the program is 32 bytes <code>hash</code>:
<ul>
<li>If <code>input</code> is empty, or its top element's SHA256 hash does not equal <code>hash</code>, fail.</li>
<li>Execute the top element of <code>input</code> as script, with the other elements as input. If execution aborts, fail.</li>
<li>If the resulting stack is not exactly one element, or that element has numerical value 0, fail.</li>
</ul>
</li>
</ul>
</li>
<li>[From <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">BIP341]</a> If the version is 1, the program length is 32, and this is not operating inside a P2SH wrapping:
<ul>
<li>If the <code>input</code> consists of 0 elements, fail.</li>
<li>If the last element of <code>input</code> starts with byte 0x50, call it the <code>annex</code> and remove it from the <code>input</code>.</li>
<li>If the (remainder of) <code>input</code> consists of a single element, evaluate it as a Taproot key path spend:
<ul>
<li>The element is interpreted as a single <a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki" rel="nofollow noreferrer">BIP340</a> (Schnorr) signature for the transaction, using a message hashing scheme described in BIP341. If the signature is invalid, fail.</li>
</ul>
</li>
<li>If the (remainder of) <code>input</code> consists of two or more elements, evaluate it as a Taproot script path spend:
<ul>
<li>The last element of <code>input</code> is interpreted as a Taproot control block, encoding a <code>leaf_version</code>, an internal x-only public key, and a Merkle path, and the penultimate element of <code>input</code> is called the <code>taproot_script</code>. The control block and <code>taproot_script</code> are removed from <code>input</code>.
<ul>
<li>Recompute the Merkle root of the script tree, starting from the leaf (<code>leaf_version</code> and <code>taproot_script</code>), and then tweak the internal x-only key with that Merkle root. If the result does not match the 32-byte witness program, fail.</li>
<li>[From <a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki" rel="nofollow noreferrer">BIP342]</a> If the <code>leaf_version</code> is 0xc0, <code>taproot_script</code> is evaluated according to the Tapscript validation rules, with the remaining of <code>input</code> as initial stack. See BIP342 for how this differs from normal script execution.</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>If no failure occurred up to this point, return success.</li>
</ul>
<p>Source: <a href="https://github.com/bitcoin/bitcoin/blob/v25.0/src/script/interpreter.cpp" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/v25.0/src/script/interpreter.cpp</a>, functions <code>VerifyScript</code>, <code>VerifyWitnessProgram</code>, <code>ExecuteWitnessScript</code>.</p>
<p>TL;DR: only the BIP16 P2SH pattern (OP_HASH160 &lt;20 bytes&gt; OP_EQUAL) and the BIP141 segwit pattern (OP_n &lt;2 to 40 bytes&gt;) are actual special cases that trigger additional rules. But the details are more complex.</p>

CC BY-SA 4.0
2021-03-26T17:38:54.497Z
In the P2SH wrapped case, should this be "Run segwit validation with the top element of `result` as program" (instead of `scriptPubKey` as program)?
Elliott
CC BY-SA 4.0
2023-08-31T14:58:52.440Z
@Elliott Fixed.
Pieter Wuille
CC BY-SA 4.0
2023-09-01T15:58:52.267Z
@PieterWuille For P2SH validation you wrote: "If scriptSig does not consists of only pushes, fail." But the redeem script (i.e. the top element of `result`) can contain whatever OP codes we want?
dassd
CC BY-SA 4.0
2023-09-01T16:19:29.463Z
Yes, the scriptSig must consist of only pushes. The last of those push is the redeemscript, which *when the data being pushed is interpreted as a script* contains opcodes.
Pieter Wuille
CC BY-SA 4.0
2023-09-01T16:26:17.520Z
@PieterWuille I didn't ask the question well. I wanted to say that the redeem script can contain any opcodes we want, they don't have to be push only?
dassd
CC BY-SA 4.0
2023-09-01T16:26:48.510Z
Yes, the redeemscript is any script, it can contain any opcodes. It's just the scriptSig that must be push only for P2SH spends.
Pieter Wuille
CC BY-SA 4.0
2023-09-01T16:37:56.700Z
@PieterWuille Taproot (BIP341, BIP342) doesn't break any of the rules you wrote in your answer? It would represent just another "if the version is 1" in the Segwit validation section with some rules of its own?
dassd
CC BY-SA 4.0
2023-09-01T16:38:57.107Z
@joke Correct, it's just adding a "if version is 1, witness program is 32 bytes, ..." branch.
Pieter Wuille
CC BY-SA 4.0
2023-09-01T23:35:04.587Z
@PieterWuille Couple of additional questions. 1) For P2WSH in P2SH you wrote: "If `scriptSig` is not exactly a direct push of the top element of `result`, fail.". Does it mean that in this case any additional pushes are not allowed (opposite to P2SH)? So only the push of the redeem script and the redeem script is "OP_n (with n between 0 and 16, inclusive) followed by a direct push of exactly 2 to 40 bytes". 2) For P2WSH you wrote "If `input` is empty, or its top element's SHA256 `hash` does not equal hash, fail.", is it more accurate to say `the last item of witness data` since it's not stack?
dassd
CC BY-SA 4.0
2023-09-01T23:35:17.730Z
@PieterWuille 3) For P2WSH you wrote "Execute the top element of `input` as script, with the other elements as input. If execution aborts, fail.". Are these other elements i.e. the other elements in the witness data, the initial stack? 4) Do these other items have to be push only, like in classic P2SH, or can some other OP codes as well?
dassd
CC BY-SA 4.0
2023-09-02T00:41:38.047Z
1) Yes, no other pushes are allowed (because inputs need to provided through witness, not through scriptSig). 2) The list of witness items is called a stack too, though admittedly that name isn't very accurate. But yes, last element. 3) Yes, for P2WSH the witness stack consists of the witness script's inputs, followed by the witness script itself. All but the last element become the initial stack for execution. 4) The witness stack is not a script, it's just a list of elements; it has no notion of opcodes or pushes - rather, it's the resulting script stack itself.
Pieter Wuille
CC BY-SA 4.0
2023-09-02T00:52:02.380Z
@PieterWuille Okay, for the last (4) question/answer. In P2SH, the scriptSig consists only of OP_CODES for push + the data being pushed and the last push is the redeem script. In P2WSH, there is no push OP_CODES in the witness script, it is just one element next to another, which will be placed in order on the stack, while the last one will represent the redeem script itself which will work with previous items as initial stack. So there are no classic: op_code_push data, op_code_push data etc. as in P2SH, instead it goes: data data data (last data = redeem script) etc.?
dassd
CC BY-SA 4.0
2023-09-02T01:03:12.657Z
All correct. The witness stack is just an array of byte arrays. For P2WSH the last one is interpreted as the witness script, the rest becomes the initial script execution stack.
Pieter Wuille
CC BY-SA 4.0
2023-09-07T10:40:25.920Z
@PieterWuille You wrote that `If the top element of result is exactly OP_n (with n between 0 and 16 inclusive) followed by a direct push of 2 through 40 bytes inclusive` SegWit validation is started. For SegWit, you only wrote the `if case` for version 0 (and let's assume for version 1). But what will happen if the version is, for example, `2` or `3`? Will it be recognized as a normal SegWit and then checked the scriptsig. If it is not empty, an error is thrown, and if it is, the script is immediately accepted without any additional checks of witness data since `if case` for v2/v3 not exist?
dassd
CC BY-SA 4.0
2023-09-07T12:08:16.137Z
Indeed. Future segwit versions are effectively anyone-can-spend outputs (until there is a consensus change that does introduce rules for them, of course), subject to things like empty scriptSig.
Pieter Wuille
CC BY-SA 4.0
2023-09-08T13:09:11.663Z
@PieterWuille Sorry, but no sure if I understood correctly `subject to things like empty scriptSig`. So, for example scriptPubKey `OP_2 <26-bytes>` will be recognized as segWit since it is, as you said: `exactly equal to an OP_n (with n between 0 and 16, inclusive) followed by a direct push of exactly 2 to 40 bytes`. Since nothing has been defined for v2 yet, it will be anyone-can-spend and only check will be if the scriptSig is empty. Empty = accept, otherwise not. The content of witness is not important in this case (it will become important after the rules for v2 are introduced). Right?
dassd
CC BY-SA 4.0
2023-09-08T13:15:54.960Z
@joke All correct. The contents of the witness does not matter when spending a v2 segwit output (for now). If the scriptSig is not empty (or in the case of P2SH-segwit, consist of more than the redeemScript), that makes the spend invalid. Also, non-segwit outputs require that no witness is provided when spending them.
Pieter Wuille
CC BY-SA 4.0
2023-09-14T22:53:15.990Z
@PieterWuille Should it be added for P2WPKH right at the beginning that `if the input is empty, fail`?
dassd
CC BY-SA 4.0
2023-09-15T00:30:45.297Z
@joke There is no separate rule needed for that, actually, nor do I believe such a rule is implemented. If the input is empty, the execution of the `OP_DUP OP_HASH160 ...` script will fail.
Pieter Wuille
CC BY-SA 4.0
2023-09-18T19:59:29.980Z
@PieterWuille Checking whether the input (witness data) is empty does not exist in P2WPKH, but is there a check that there are exactly 2 elements? Vojtěch Strnad wrote in [his answer](https://bitcoin.stackexchange.com/a/119716/144381)  that such a check exists.
dassd
CC BY-SA 4.0
2023-09-18T22:08:55.570Z
@joke There is no specific separate rule for that either in implementations. If there are not exactly 2 input elements for implicit P2WPKH script, it will fail execution (due to the "cleanstack" rule that says exactly 1 element must be left after execution). You can certainly say that to be a valid P2WPKH spend must have 2 witness input items, but whether or not you consider that also a *rule* is unovservable.
Pieter Wuille
CC BY-SA 4.0
2023-09-18T22:18:03.397Z
@PieterWuille What about [this](https://github.com/bitcoin/bitcoin/blob/v25.0/src/script/interpreter.cpp#L1895)?
dassd
CC BY-SA 4.0
2023-09-19T07:12:11.543Z
@joke Interesting. I misremembered, and you're totally right; both the specification in BIP141 and the implementation in Bitcoin Core specifically check for 2 stack elements exactly. I still believe that this rule is unnecessary (the exact same scripts/witnesses would succeed and fail without it), but my claim in the comment above was wrong.
Pieter Wuille
CC BY-SA 4.0
2021-01-06T01:28:00.703Z
2023-09-19T07:09:39.637Z
2023-09-19T07:09:39.637Z
Pieter Wuille
<p>When executing a Bitcoin Script, there are some &quot;special cases&quot; where the interpreter performs extra verification beyond just executing <code>scriptSig</code> and then <code>scriptPubKey</code>.</p>
<p>For example, if the <code>scriptPubKey</code> has the following specific format:</p>
<pre><code>OP_HASH160 &lt;20 byte hash&gt; OP_EQUAL
</code></pre>
<p>then the interpreter will additionally apply the <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki" rel="noreferrer">BIP 0016 &quot;Pay to Script Hash&quot; (P2SH)</a> rules.</p>
<p><strong>What's the full list of &quot;special cases&quot; that could be encountered during Script execution, and when is each encountered?</strong></p>

<script><transaction-verification>
Full list of "special cases" during Bitcoin Script execution (p2sh, p2wsh, etc.)?
Elliott
# Full list of "special cases" during Bitcoin Script execution (p2sh, p2wsh, etc.)?

(Asked by: username_0 on 2021-01-06)

When executing a Bitcoin Script, there are some "special cases" where the interpreter performs extra verification beyond just executing `scriptSig` and then `scriptPubKey`.

For example, if the `scriptPubKey` has the following specific format:

```
OP_HASH160 <20 byte hash> OP_EQUAL

```

then the interpreter will additionally apply the [BIP 0016 "Pay to Script Hash" (P2SH)](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki) rules.

**What's the full list of "special cases" that could be encountered during Script execution, and when is each encountered?**

**Tags:** script, transaction-verification


---

## 1 answers

### Answer by username_1 on 2021-01-06. Score: 15 | Accepted answer

As of September 2023, "high-level" script validation with all active consensus rules on the network is approximately this:

### Top level evaluation

* Execute the `scriptSig`, and call the resulting stack `stack`. If execution aborts, fail.
* Execute the `scriptPubKey` with `stack` as input, and call the resulting stack `result`. If execution aborts, fail.
* If `result` is empty, or its top element has numerical value 0, fail.
* [from [BIP141]](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) If `scriptPubKey` is exactly equal to an OP\_n (with `n` between 0 and 16, inclusive) followed by a direct push of exactly 2 to 40 bytes inclusive:
  + If `scriptSig` not empty, fail.
  + Run segwit validation with the 2-to-40 byte push in `scriptPubKey` as program, the `n` value as version, and `witness` as input (see further). If this execution aborts, fail.
* [From [BIP16]](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki) If `scriptPubKey` is exactly equal to OP\_HASH160 + a 20 byte push + OP\_EQUAL, run P2SH validation:
  + If `scriptSig` does not consists of only pushes, fail.
  + If `result` is empty, fail.
  + Interpret the top element of `result` as a script, and execute it, with the rest of `result` as input. Call the resulting stack `p2sh_result`. If this execution aborts, fail.
  + If `p2sh_result` is empty, or its top element has numerical value 0, fail.
  + [From [BIP141]](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) If the top element of `result` is exactly OP\_n (with `n` between 0 and 16 inclusive) followed by a direct push of 2 through 40 bytes inclusive:
    - If `scriptSig` is not exactly a direct push of the top element of `result`, fail.
    - Run segwit validation with the 2-to-40 byte push in the top element of `result` as program, the `n` value as version, and `witness` as input (see further). If this execution aborts, fail.
* If segwit validation did *not* trigger, but a witness is provided in the transaction input, fail.
* If no failure occurred before this point, the input is valid.

### Segwit validation

Segwit validation for version `version`, with program `program`, and input `input`:

* [From [BIP141]](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) If the version is 0:
  + If the program is not 20 or 32 bytes, fail.
  + If the program is 20 bytes `hash`:
    - If `input` is not exactly 2 elements, fail.
    - Execute the script OP\_DUP OP\_HASH160 `hash` OP\_EQUALVERIFY OP\_CHECKSIG, with initial stack `input`. If execution aborts, fail.
    - If the resulting stack is not exactly one element, or that element has numerical value 0, fail.
  + If the program is 32 bytes `hash`:
    - If `input` is empty, or its top element's SHA256 hash does not equal `hash`, fail.
    - Execute the top element of `input` as script, with the other elements as input. If execution aborts, fail.
    - If the resulting stack is not exactly one element, or that element has numerical value 0, fail.
* [From [BIP341]](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) If the version is 1, the program length is 32, and this is not operating inside a P2SH wrapping:
  + If the `input` consists of 0 elements, fail.
  + If the last element of `input` starts with byte 0x50, call it the `annex` and remove it from the `input`.
  + If the (remainder of) `input` consists of a single element, evaluate it as a Taproot key path spend:
    - The element is interpreted as a single [BIP340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) (Schnorr) signature for the transaction, using a message hashing scheme described in BIP341. If the signature is invalid, fail.
  + If the (remainder of) `input` consists of two or more elements, evaluate it as a Taproot script path spend:
    - The last element of `input` is interpreted as a Taproot control block, encoding a `leaf_version`, an internal x-only public key, and a Merkle path, and the penultimate element of `input` is called the `taproot_script`. The control block and `taproot_script` are removed from `input`.
      * Recompute the Merkle root of the script tree, starting from the leaf (`leaf_version` and `taproot_script`), and then tweak the internal x-only key with that Merkle root. If the result does not match the 32-byte witness program, fail.
      * [From [BIP342]](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki) If the `leaf_version` is 0xc0, `taproot_script` is evaluated according to the Tapscript validation rules, with the remaining of `input` as initial stack. See BIP342 for how this differs from normal script execution.
* If no failure occurred up to this point, return success.

Source: <https://github.com/bitcoin/bitcoin/blob/v25.0/src/script/interpreter.cpp>, functions `VerifyScript`, `VerifyWitnessProgram`, `ExecuteWitnessScript`.

TL;DR: only the BIP16 P2SH pattern (OP\_HASH160 <20 bytes> OP\_EQUAL) and the BIP141 segwit pattern (OP\_n <2 to 40 bytes>) are actual special cases that trigger additional rules. But the details are more complex.

> **Comments:**
> **username_0**: In the P2SH wrapped case, should this be "Run segwit validation with the top element of `result` as program" (instead of `scriptPubKey` as program)?  
> **username_1**: @username_0 Fixed.  
> **username_2**: @username_1 For P2SH validation you wrote: "If scriptSig does not consists of only pushes, fail." But the redeem script (i.e. the top element of `result`) can contain whatever OP codes we want?  
> **username_1**: Yes, the scriptSig must consist of only pushes. The last of those push is the redeemscript, which *when the data being pushed is interpreted as a script* contains opcodes.  
> **username_2**: @username_1 I didn't ask the question well. I wanted to say that the redeem script can contain any opcodes we want, they don't have to be push only?  
> **username_1**: Yes, the redeemscript is any script, it can contain any opcodes. It's just the scriptSig that must be push only for P2SH spends.  
> **username_2**: @username_1 Taproot (BIP341, BIP342) doesn't break any of the rules you wrote in your answer? It would represent just another "if the version is 1" in the Segwit validation section with some rules of its own?  
> **username_1**: @joke Correct, it's just adding a "if version is 1, witness program is 32 bytes, ..." branch.  
> **username_2**: @username_1 Couple of additional questions. 1) For P2WSH in P2SH you wrote: "If `scriptSig` is not exactly a direct push of the top element of `result`, fail.". Does it mean that in this case any additional pushes are not allowed (opposite to P2SH)? So only the push of the redeem script and the redeem script is "OP_n (with n between 0 and 16, inclusive) followed by a direct push of exactly 2 to 40 bytes". 2) For P2WSH you wrote "If `input` is empty, or its top element's SHA256 `hash` does not equal hash, fail.", is it more accurate to say `the last item of witness data` since it's not stack?  
> **username_2**: @username_1 3) For P2WSH you wrote "Execute the top element of `input` as script, with the other elements as input. If execution aborts, fail.". Are these other elements i.e. the other elements in the witness data, the initial stack? 4) Do these other items have to be push only, like in classic P2SH, or can some other OP codes as well?  
> **username_1**: 1) Yes, no other pushes are allowed (because inputs need to provided through witness, not through scriptSig). 2) The list of witness items is called a stack too, though admittedly that name isn't very accurate. But yes, last element. 3) Yes, for P2WSH the witness stack consists of the witness script's inputs, followed by the witness script itself. All but the last element become the initial stack for execution. 4) The witness stack is not a script, it's just a list of elements; it has no notion of opcodes or pushes - rather, it's the resulting script stack itself.  
> **username_2**: @username_1 Okay, for the last (4) question/answer. In P2SH, the scriptSig consists only of OP_CODES for push + the data being pushed and the last push is the redeem script. In P2WSH, there is no push OP_CODES in the witness script, it is just one element next to another, which will be placed in order on the stack, while the last one will represent the redeem script itself which will work with previous items as initial stack. So there are no classic: op_code_push data, op_code_push data etc. as in P2SH, instead it goes: data data data (last data = redeem script) etc.?  
> **username_1**: All correct. The witness stack is just an array of byte arrays. For P2WSH the last one is interpreted as the witness script, the rest becomes the initial script execution stack.  
> **username_2**: @username_1 You wrote that `If the top element of result is exactly OP_n (with n between 0 and 16 inclusive) followed by a direct push of 2 through 40 bytes inclusive` SegWit validation is started. For SegWit, you only wrote the `if case` for version 0 (and let's assume for version 1). But what will happen if the version is, for example, `2` or `3`? Will it be recognized as a normal SegWit and then checked the scriptsig. If it is not empty, an error is thrown, and if it is, the script is immediately accepted without any additional checks of witness data since `if case` for v2/v3 not exist?  
> **username_1**: Indeed. Future segwit versions are effectively anyone-can-spend outputs (until there is a consensus change that does introduce rules for them, of course), subject to things like empty scriptSig.  
> **username_2**: @username_1 Sorry, but no sure if I understood correctly `subject to things like empty scriptSig`. So, for example scriptPubKey `OP_2 <26-bytes>` will be recognized as segWit since it is, as you said: `exactly equal to an OP_n (with n between 0 and 16, inclusive) followed by a direct push of exactly 2 to 40 bytes`. Since nothing has been defined for v2 yet, it will be anyone-can-spend and only check will be if the scriptSig is empty. Empty = accept, otherwise not. The content of witness is not important in this case (it will become important after the rules for v2 are introduced). Right?  
> **username_1**: @joke All correct. The contents of the witness does not matter when spending a v2 segwit output (for now). If the scriptSig is not empty (or in the case of P2SH-segwit, consist of more than the redeemScript), that makes the spend invalid. Also, non-segwit outputs require that no witness is provided when spending them.  
> **username_2**: @username_1 Should it be added for P2WPKH right at the beginning that `if the input is empty, fail`?  
> **username_1**: @joke There is no separate rule needed for that, actually, nor do I believe such a rule is implemented. If the input is empty, the execution of the `OP_DUP OP_HASH160 ...` script will fail.  
> **username_2**: @username_1 Checking whether the input (witness data) is empty does not exist in P2WPKH, but is there a check that there are exactly 2 elements? Vojtěch Strnad wrote in [his answer](https://bitcoin.stackexchange.com/a/119716/144381)  that such a check exists.  
> **username_1**: @joke There is no specific separate rule for that either in implementations. If there are not exactly 2 input elements for implicit P2WPKH script, it will fail execution (due to the "cleanstack" rule that says exactly 1 element must be left after execution). You can certainly say that to be a valid P2WPKH spend must have 2 witness input items, but whether or not you consider that also a *rule* is unovservable.  
> **username_2**: @username_1 What about [this](https://github.com/bitcoin/bitcoin/blob/v25.0/src/script/interpreter.cpp#L1895)?  
> **username_1**: @joke Interesting. I misremembered, and you're totally right; both the specification in BIP141 and the implementation in Bitcoin Core specifically check for 2 stack elements exactly. I still believe that this rule is unnecessary (the exact same scripts/witnesses would succeed and fail without it), but my claim in the comment above was wrong.  

---

