From: Pieter Wuille <pieter.wuille@gmail•com>
To: Rusty Russell <rusty@rustcorp•com.au>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
Date: Sun, 25 Jan 2015 10:34:08 -0400 [thread overview]
Message-ID: <CAPg+sBjQAi_hCcoV0gecVQAd4PYKzRd5F_nymz8UVt9BFg8O2Q@mail.gmail.com> (raw)
In-Reply-To: <87egqnwt7g.fsf@rustcorp.com.au>
On Wed, Jan 21, 2015 at 8:32 PM, Rusty Russell <rusty@rustcorp•com.au> wrote:
> One weirdness is the restriction on maximum total length, rather than a
> 32 byte (33 with 0-prepad) limit on signatures themselves.
Glad that you point this out; I believe that's a weakness with more
impact now that this function is used for consensus. Let me clarify.
This function was originally written for Bitcoin Core v0.8.0, where it
was only used to enforce non-standardness, not consensus. In that
setting, there was no need to require a maximum length for the R and S
arguments, as overly-long R or S values (which, because of a further
rule, do not have excessive padding) will always result in integers >=
2^256, which means the encoded signature would never be valid
according to the ECDSA specification. A restriction on the total
length is required however, as BER allows multi-byte length
descriptors, which this function cannot (and shouldn't, as it's not
DER) parse.
However, in the currently proposed soft fork, non-DER results in
immediate script failure, which is distinguishable from invalid
signatures (by negating the result of a CHECKSIG, for example using a
NOT after it). I must admit that having invalid signatures with
overly-long R or S but acceptable R+S size be distinguishable from
invalid signatures where R+S is too large is ugly, and unnecessary.
Adding individual R and S length restrictions (ideally: saying that no
more than 32 bytes, excluding the padding 0 byte in front, is invalid)
would be trivial, but it means deviating slightly from the
standardness rule implementation that has been deployed for a while.
There should not really be much risk in doing so, as there are still
no node implementation releases (apart from the v0.10.0 rc's) that
would mine a CHECKSIG whose result is negated.
So, I think there are two options:
* Just add this R/S length restriction rule as a standardness
requirement, but not make it part of the soft fork. A later softfork
can then add this easily. The same can be done for several other
changes if they are deemed useful, like only allowing 0 (the empty
array) as invalid signature (any other causes failure script
immediately), requiring correct encoding even for non-evaluated
signatures, ...
* Add it to the softfork now, and be done with it.
Opinions?
--
Pieter
next prev parent reply other threads:[~2015-01-25 14:34 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 0:35 Pieter Wuille
2015-01-21 4:45 ` Rusty Russell
2015-01-21 16:49 ` Pieter Wuille
2015-01-21 19:10 ` Peter Todd
2015-01-21 19:29 ` Douglas Roark
2015-01-21 20:30 ` Pieter Wuille
2015-01-21 20:39 ` Douglas Roark
2015-01-21 20:37 ` Gavin Andresen
2015-01-21 20:52 ` Douglas Roark
2015-01-21 21:22 ` Pieter Wuille
2015-01-21 20:27 ` Andrew Poelstra
2015-01-21 22:57 ` Dave Collins
2015-01-22 0:32 ` Rusty Russell
2015-01-22 3:12 ` David Vorick
2015-01-22 4:18 ` Matt Whitlock
2015-01-22 4:20 ` Pieter Wuille
2015-01-25 14:34 ` Pieter Wuille [this message]
2015-01-25 14:48 ` Gregory Maxwell
2015-02-03 0:44 ` Pieter Wuille
2015-02-03 2:21 ` Gregory Maxwell
2015-02-03 12:00 ` Wladimir
2015-02-03 14:30 ` Alex Morcos
2015-02-03 18:15 ` Pieter Wuille
2015-02-03 18:19 ` Gavin Andresen
2015-02-03 19:22 ` Jeff Garzik
2015-02-03 23:38 ` Pieter Wuille
2015-01-22 22:41 ` Zooko Wilcox-OHearn
2015-01-25 16:57 ` Pieter Wuille
2015-01-26 5:14 ` Pieter Wuille
2015-01-26 18:35 ` Gregory Maxwell
2015-01-28 6:24 ` Wladimir
2015-02-06 21:38 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPg+sBjQAi_hCcoV0gecVQAd4PYKzRd5F_nymz8UVt9BFg8O2Q@mail.gmail.com \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=rusty@rustcorp$(echo .)com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox