> On 21 Sep 2017, at 3:29 AM, Mark Friedenbach <m...@friedenbach.org> wrote: > > >> On Sep 19, 2017, at 10:13 PM, Johnson Lau <jl2...@xbt.hk> wrote: >> >> If we don’t want this ugliness, we could use a new script version for every >> new op code we add. In the new BIP114 (see link above), I suggest to move >> the script version to the witness, which is cheaper. > > To be clear, I don’t think it is so much that the version should be moved to > the witness, but rather that there are two separate version values here — one > in the scriptPubKey which specifies the format and structure of the segwit > commitment itself, and another in the witness which gates functionality in > script or whatever else is used by that witness type. Segwit just > unfortunately didn’t include the latter, an oversight that should be > corrected on the on the next upgrade opportunity. > > The address-visible “script version” field should probably be renamed > “witness type” as it will only be used in the future to encode how to check > the witness commitment in the scriptPubKey against the data provided in the > witness. Upgrades and improvements to the features supported by those witness > types won’t require new top-level witness types to be defined. Defining a new > opcode, even one with modifies the stack, doesn’t change the hashing scheme > used by the witness type. > > v0,32-bytes is presently defined to calculate the double-SHA256 hash of the > top-most serialized item on the stack, and compare that against the 32-byte > commitment value. Arguably it probably should have hashed the top two values, > one of which would have been the real script version. This could be fixed > however, even without introducing a new witness type. Do a soft-fork upgrade > that checks if the witness redeem script is push-only, and if so then pop the > last push off as the script version (>= 1), and concatenate the rest to form > the actual redeem script. We inherit a little technical debt from having to > deal with push limits, but we avoid burning v0 in an upgrade to v1 that does > little more than add a script version. > > v1,32-bytes would then be used for a template version of MAST, or whatever > other idea comes along that fundamentally changes the way the witness > commitment is calculated. > > Mark
This is exactly what I suggest with BIP114. Using v1, 32-byte to define the basic structure of Merklized Script, and define the script version inside the witness Johnson _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
