Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2014-07-19 📝 Original message:On Jul 18, 2014 4:56 PM, ...
📅 Original date posted:2014-07-19
📝 Original message:On Jul 18, 2014 4:56 PM, "Wladimir" <laanwj at gmail.com> wrote:
>
> On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn <mike at plan99.net> wrote:
> > The rationale doesn't seem to apply to rule #4, what's so special about
that
> > one?
>
> > 4. Non-push operations in scriptSig Any non-push operation in a
scriptSig invalidates it.
>
> Having non-push operations in the scriptSig is a source of
> malleability, as there can be multiple sequences of opcodes that
> evaluate to the same result.
Well yes, but that is true for each of the rules and is already covered by
the previous specification in BIP62. Making it mandatory even for old
transaction does not really protect much against malleability as there are
several other sources of malleability that cannot be made mandatory in old
transactions left.
The reason for including #4 is just "allowing this does not benefit anyone".
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140719/cc74f9a6/attachment.html>
📝 Original message:On Jul 18, 2014 4:56 PM, "Wladimir" <laanwj at gmail.com> wrote:
>
> On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn <mike at plan99.net> wrote:
> > The rationale doesn't seem to apply to rule #4, what's so special about
that
> > one?
>
> > 4. Non-push operations in scriptSig Any non-push operation in a
scriptSig invalidates it.
>
> Having non-push operations in the scriptSig is a source of
> malleability, as there can be multiple sequences of opcodes that
> evaluate to the same result.
Well yes, but that is true for each of the rules and is already covered by
the previous specification in BIP62. Making it mandatory even for old
transaction does not really protect much against malleability as there are
several other sources of malleability that cannot be made mandatory in old
transactions left.
The reason for including #4 is just "allowing this does not benefit anyone".
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140719/cc74f9a6/attachment.html>