Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.176 as permitted sender)
	client-ip=209.85.223.176; envelope-from=gmaxwell@gmail.com;
	helo=mail-ie0-f176.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAPg+sBj62GwsBAEpTPWR+Lk4xgT1snUHt=3QpHQwTpCxKXzmAQ@mail.gmail.com>
References: <CAPg+sBhk7F2OHT64i2LNSjv8DR5tD3RJkLJGzPGZW8OPQTCjQw@mail.gmail.com>
	<CAPg+sBj62GwsBAEpTPWR+Lk4xgT1snUHt=3QpHQwTpCxKXzmAQ@mail.gmail.com>
Date: Mon, 26 Jan 2015 18:35:47 +0000
Message-ID: <CAAS2fgRy0-ORuZ-o02uszqRE+9e5sZNf-OewmsZFoHZpem8mcA@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 Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
>> I therefore propose a softfork to make non-DER signatures illegal
>> (they've been non-standard since v0.8.0). A draft BIP text can be
>> found on:
>>
>>     https://gist.github.com/sipa/5d12c343746dad376c80
>
> I'd like to request a BIP number for this.

Sure. BIP0066. There was also some feedback on Bitcointalk, which I
think you've addressed:
https://bitcointalk.org/index.php?topic=932054.0 I also had off-list
positive feedback from Amir Taak, so we have positive feedback from
several implementers.

One of the points that was raised which we'd discussed pre-proposal
that was brought up there that I thought I should summarize here was
the possibility that someone had previously authored an nlocked spend
with an invalidly encoded signature. In those cases the signature can
just be mutated to get it mined, and would need to be already to pass
IsStandard rules. A case that isn't covered if if they have a chain of
transactions after that nlocked transaction, but those cases would
already be at extreme risk of malleability (esp since their unchanged
form is non-standard), and that coupled with the fact that avoiding
this would undermine the intent of the BIP (independence from  a
specific encoding scheme) seems to have been convincing as much.