1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
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 <gmaxwell@gmail.com>) id 1YFoVt-0001Nq-Pb
for bitcoin-development@lists.sourceforge.net;
Mon, 26 Jan 2015 18:35:53 +0000
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;
Received: from mail-ie0-f176.google.com ([209.85.223.176])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YFoVs-00010c-QW
for bitcoin-development@lists.sourceforge.net;
Mon, 26 Jan 2015 18:35:53 +0000
Received: by mail-ie0-f176.google.com with SMTP id rd18so10432457iec.7
for <bitcoin-development@lists.sourceforge.net>;
Mon, 26 Jan 2015 10:35:48 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.42.97.66 with SMTP id m2mr21677397icn.48.1422297348580; Mon,
26 Jan 2015 10:35:48 -0800 (PST)
Received: by 10.107.6.209 with HTTP; Mon, 26 Jan 2015 10:35:47 -0800 (PST)
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
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
(gmaxwell[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: 1YFoVs-00010c-QW
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: Mon, 26 Jan 2015 18:35:53 -0000
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.
|
