<p>If this question is about the recently published bip-taproot proposal, the answer is no, you cannot use a v0 script inside a v1 output.</p>

<p>The general reason for this is that some of the goals the BIP is trying to achieve are incompatible with v0 scripts. That on itself doesn't make it impossible to support v0 scripts, but reasoning about the benefits of the changes is much easier if you know there is no way to bypass them. Furthermore, the changes between (the initial set of) supported features in v1 and v0 is small:</p>

<ul>
<li><strong>No CHECKMULTISIG</strong> The OP_CHECKMULTISIG opcode is unnecessarily inefficient, as it sometimes needs to try multiple combinations of public keys with signatures. Furthermore, it is not compatible with batch validation (the ability to verify all signatures in a block faster than verifying them individually). As multisig constructions are very useful, a replacement opcode is available: OP_CHECKSIGADD, which increments a counter based on whether or not a signature check succeeded.</li>
<li><strong>Schnorr instead of ECDSA</strong> All opcodes that take ECDSA signatures in v0 are changed to take Schnorr signatures instead. They're more efficient, but also ECDSA does not support batch validation, conflicting with one of bip-taproot's design goals.</li>
<li><strong>Improved sighashing</strong> Some improvements are made to the hash that's signed in signatures to resolve a few long-standing issues. If there was a way to bypass these improvements it would be hard for other participants in a transaction to rely on these fixes being guaranteed.</li>
</ul>

CC BY-SA 4.0
2019-05-09T18:51:33.783Z
Was this an easy decision to make or were privacy benefits of merged implementation significant argument?
Wapac
CC BY-SA 4.0
2019-05-09T19:36:06.853Z
I don't understand what privacy has to do with this. Arguably by providing less options you marginally improve privacy (as the choice for v0 vs v1 does not leak).
Pieter Wuille
CC BY-SA 4.0
2019-05-09T20:10:17.600Z
If I understand you correctly, basically you're saying that there wasn't a way to design it in a way to merge v0 scripts with v1 so that they are not distinguishable (same scriptPubKey format). Therefore no privacy benefits of merging, correct?
Wapac
CC BY-SA 4.0
2019-05-09T21:10:34.227Z
All v1 **outputs** would be indistinguishable from each other thanks to Taproot (but distinguishable from v0 outputs). The leaf version (which determines what script rules are used) is only revealed when actually executing the script path (which is hopefully rare). Your question is (I think) whether we could have a leaf version under v1 that lets scripts be interpreted similar to v0 scripts. My answer is that that would be both a privacy reduction (when actually spending you'd need to reveal what script semantics are in use), and reducing the benefits in terms of achieve bip-taproot's goals.
Pieter Wuille
CC BY-SA 4.0
2019-05-28T17:39:58.123Z
Is there a reason you've excluded OP_SUCCESS and MINIMALIF from this answer?
jnewbery
CC BY-SA 4.0
2019-05-09T16:39:37.807Z
2019-05-09T16:39:37.807Z
Pieter Wuille
<p>My question is whether the version 1 of Segwit script will allow you to use version 0 scripts types inside of it. In other words, is version 1 superset of version 0? Please include reasoning behind the design decision.</p>

<segregated-witness><taproot>
Does v1 Segwit includes v0?
Wapac
# Does v1 Segwit includes v0?

(Asked by: username_0 on 2019-05-09)

My question is whether the version 1 of Segwit script will allow you to use version 0 scripts types inside of it. In other words, is version 1 superset of version 0? Please include reasoning behind the design decision.

**Tags:** segregated-witness, taproot


---

## 1 answers

### Answer by username_1 on 2019-05-09. Score: 5 | Accepted answer

If this question is about the recently published bip-taproot proposal, the answer is no, you cannot use a v0 script inside a v1 output.

The general reason for this is that some of the goals the BIP is trying to achieve are incompatible with v0 scripts. That on itself doesn't make it impossible to support v0 scripts, but reasoning about the benefits of the changes is much easier if you know there is no way to bypass them. Furthermore, the changes between (the initial set of) supported features in v1 and v0 is small:

* **No CHECKMULTISIG** The OP\_CHECKMULTISIG opcode is unnecessarily inefficient, as it sometimes needs to try multiple combinations of public keys with signatures. Furthermore, it is not compatible with batch validation (the ability to verify all signatures in a block faster than verifying them individually). As multisig constructions are very useful, a replacement opcode is available: OP\_CHECKSIGADD, which increments a counter based on whether or not a signature check succeeded.
* **Schnorr instead of ECDSA** All opcodes that take ECDSA signatures in v0 are changed to take Schnorr signatures instead. They're more efficient, but also ECDSA does not support batch validation, conflicting with one of bip-taproot's design goals.
* **Improved sighashing** Some improvements are made to the hash that's signed in signatures to resolve a few long-standing issues. If there was a way to bypass these improvements it would be hard for other participants in a transaction to rely on these fixes being guaranteed.

> **Comments:**
> **username_0**: Was this an easy decision to make or were privacy benefits of merged implementation significant argument?  
> **username_1**: I don't understand what privacy has to do with this. Arguably by providing less options you marginally improve privacy (as the choice for v0 vs v1 does not leak).  
> **username_0**: If I understand you correctly, basically you're saying that there wasn't a way to design it in a way to merge v0 scripts with v1 so that they are not distinguishable (same scriptPubKey format). Therefore no privacy benefits of merging, correct?  
> **username_1**: All v1 **outputs** would be indistinguishable from each other thanks to Taproot (but distinguishable from v0 outputs). The leaf version (which determines what script rules are used) is only revealed when actually executing the script path (which is hopefully rare). Your question is (I think) whether we could have a leaf version under v1 that lets scripts be interpreted similar to v0 scripts. My answer is that that would be both a privacy reduction (when actually spending you'd need to reveal what script semantics are in use), and reducing the benefits in terms of achieve bip-taproot's goals.  
> **username_2**: Is there a reason you've excluded OP_SUCCESS and MINIMALIF from this answer?  

---

