Mark Friedenbach [ARCHIVE] on Nostr: đź“… Original date posted:2017-09-30 đź“ť Original message:The CLEANSTACK rule should ...
đź“… Original date posted:2017-09-30
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev