4

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.

4

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.
  • Was this an easy decision to make or were privacy benefits of merged implementation significant argument? – Wapac May 9 at 18:51
  • 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 May 9 at 19:36
  • 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 May 9 at 20:10
  • 3
    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 May 9 at 21:10
  • Is there a reason you've excluded OP_SUCCESS and MINIMALIF from this answer? – jnewbery May 28 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.