The CLEANSTACK rule should be eliminated, and instead the number of items on the stack should be incorporated into the signature hash. That way any script with a CHECKSIG is protected from witness extension malleability, and those rare ones that do not use signature operations can have a “DEPTH 1 EQUALVERIFY” at the end. This allows for much simpler tail-call evaluation as you don’t need to pass arguments on the alt-stack.
> On Sep 30, 2017, at 6:13 PM, Luke Dashjr via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > I've put together a first draft for what I hope to be a good next step for > Segwit and Bitcoin scripting: > https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki > > This introduces 5 key changes: > > 1. Minor versions for witnesses, inside the witness itself. Essentially the > witness [major] version 1 simply indicates the witness commitment is SHA256d, > and nothing more. > > The remaining two are witness version 1.0 (major 1, minor 0): > > 2. As previously discussed, undefined opcodes immediately cause the script to > exit with success, making future opcode softforks a lot more flexible. > > 3. If the final stack element is not exactly true or false, it is interpreted > as a tail-call Script and executed. (Credit to Mark Friedenbach) > > 4. A new shorter fixed-length signature format, eliminating the need to guess > the signature size in advance. All signatures are 65 bytes, unless a > condition > script is included (see #5). > > 5. The ability for signatures to commit to additional conditions, expressed > in > the form of a serialized Script in the signature itself. This would be useful > in combination with OP_CHECKBLOCKATHEIGHT (BIP 115), hopefully ending the > whole replay protection argument by introducing it early to Bitcoin before > any > further splits. > > This last part is a big ugly right now: the signature must commit to the > script interpreter flags and internal "sigversion", which basically serve the > same purpose. The reason for this, is that otherwise someone could move the > signature to a different context in an attempt to exploit differences in the > various Script interpretation modes. I don't consider the BIP deployable > without this getting resolved, but I'm not sure what the best approach would > be. Maybe it should be replaced with a witness [major] version and witness > stack? > > There is also draft code implementing [the consensus side of] this: > https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1 > > Thoughts? Anything I've overlooked / left missing that would be > uncontroversial and desirable? (Is any of this unexpectedly controversial for > some reason?) > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
