Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.175 as permitted sender)
	client-ip=209.85.223.175; envelope-from=gmaxwell@gmail.com;
	helo=mail-ie0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAPg+sBjQAi_hCcoV0gecVQAd4PYKzRd5F_nymz8UVt9BFg8O2Q@mail.gmail.com>
References: <CAPg+sBhk7F2OHT64i2LNSjv8DR5tD3RJkLJGzPGZW8OPQTCjQw@mail.gmail.com>
	<87egqnwt7g.fsf@rustcorp.com.au>
	<CAPg+sBjQAi_hCcoV0gecVQAd4PYKzRd5F_nymz8UVt9BFg8O2Q@mail.gmail.com>
Date: Sun, 25 Jan 2015 14:48:10 +0000
Message-ID: <CAAS2fgQjTq1M6fF5KDiZ-qBrCWjs9z5VKtj-c1ghRfDeK6iyPA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
Precedence: list

On Sun, Jan 25, 2015 at 2:34 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> * Add it to the softfork now, and be done with it.

Initially I was of the opinion that we couldn't do that, because
soft-forks which hit transactions many nodes would relay+mine creates
a forking risk... but with the realization that imbalanced R/S plus
checksig-not would only be work with 0.10rc/git changed my mind.
Unlike two years ago miners no longer appear to be racing the bleeding
edge, and it's never show up in a release. Obviously the next RC would
also make those non-standard. And then we'll have some non-trivial
amount of time before the soft-fork activates for whatever stragglers
there are on 0.10 prerelease code to update. The deployment of the
soft-fork rules themselves will already drive people to update.

In terms of being robust to implementation differences, not permitting
overlarge R/S is obviously prudent.

So I think we should just go ahead with R/S length upper bounds as
both IsStandard and in STRICTDER.