Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-30 📝 Original message:Should it perhaps commit ...
📅 Original date posted:2017-09-30
📝 Original message:Should it perhaps commit to the length of the serialised witness data instead
or additionally? Now that signatures are no longer variable-length, that'd be
possible...
As far as tail-call needs are concerned, CLEANSTACK wouldn't have been checked
until AFTER the tail-call in the first draft. But I suppose eliminating it for
other possible future purposes is still useful.
Luke
On Sunday 01 October 2017 2:23:47 AM Mark Friedenbach wrote:
> 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:Should it perhaps commit to the length of the serialised witness data instead
or additionally? Now that signatures are no longer variable-length, that'd be
possible...
As far as tail-call needs are concerned, CLEANSTACK wouldn't have been checked
until AFTER the tail-call in the first draft. But I suppose eliminating it for
other possible future purposes is still useful.
Luke
On Sunday 01 October 2017 2:23:47 AM Mark Friedenbach wrote:
> 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