diff options
| author | Pieter Wuille <pieter.wuille@gmail.com> | 2015-01-25 10:34:08 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-01-25 14:34:18 +0000 |
| commit | 7f84216126a6b016e9e7977d2e00fbb3fb2503be (patch) | |
| tree | 07cbb23c74b7b49fa7666bbf1380ea8bcf3208dc | |
| parent | a90813ad842f7362067af50802a814b43351bf5a (diff) | |
| download | pi-bitcoindev-7f84216126a6b016e9e7977d2e00fbb3fb2503be.tar.gz pi-bitcoindev-7f84216126a6b016e9e7977d2e00fbb3fb2503be.zip | |
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
| -rw-r--r-- | ef/76372ae2ecc4efedd87659830d83b3654ba71b | 108 |
1 files changed, 108 insertions, 0 deletions
diff --git a/ef/76372ae2ecc4efedd87659830d83b3654ba71b b/ef/76372ae2ecc4efedd87659830d83b3654ba71b new file mode 100644 index 000000000..d18d18e40 --- /dev/null +++ b/ef/76372ae2ecc4efedd87659830d83b3654ba71b @@ -0,0 +1,108 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pieter.wuille@gmail.com>) id 1YFOGY-0003O6-6e + for bitcoin-development@lists.sourceforge.net; + Sun, 25 Jan 2015 14:34:18 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.223.172 as permitted sender) + client-ip=209.85.223.172; envelope-from=pieter.wuille@gmail.com; + helo=mail-ie0-f172.google.com; +Received: from mail-ie0-f172.google.com ([209.85.223.172]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YFOGR-0004r0-IU + for bitcoin-development@lists.sourceforge.net; + Sun, 25 Jan 2015 14:34:17 +0000 +Received: by mail-ie0-f172.google.com with SMTP id rd18so4760748iec.3 + for <bitcoin-development@lists.sourceforge.net>; + Sun, 25 Jan 2015 06:34:08 -0800 (PST) +MIME-Version: 1.0 +X-Received: by 10.50.43.138 with SMTP id w10mr11886455igl.19.1422196448460; + Sun, 25 Jan 2015 06:34:08 -0800 (PST) +Received: by 10.50.20.229 with HTTP; Sun, 25 Jan 2015 06:34:08 -0800 (PST) +In-Reply-To: <87egqnwt7g.fsf@rustcorp.com.au> +References: <CAPg+sBhk7F2OHT64i2LNSjv8DR5tD3RJkLJGzPGZW8OPQTCjQw@mail.gmail.com> + <87egqnwt7g.fsf@rustcorp.com.au> +Date: Sun, 25 Jan 2015 10:34:08 -0400 +Message-ID: <CAPg+sBjQAi_hCcoV0gecVQAd4PYKzRd5F_nymz8UVt9BFg8O2Q@mail.gmail.com> +From: Pieter Wuille <pieter.wuille@gmail.com> +To: Rusty Russell <rusty@rustcorp.com.au> +Content-Type: text/plain; charset=ISO-8859-1 +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (pieter.wuille[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1YFOGR-0004r0-IU +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER signatures +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Sun, 25 Jan 2015 14:34:18 -0000 + +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 + + |