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
89
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1X8ALP-0006Z0-LO
for bitcoin-development@lists.sourceforge.net;
Fri, 18 Jul 2014 15:45:11 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.171 as permitted sender)
client-ip=209.85.213.171; envelope-from=pieter.wuille@gmail.com;
helo=mail-ig0-f171.google.com;
Received: from mail-ig0-f171.google.com ([209.85.213.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X8ALO-0002E9-Qc
for bitcoin-development@lists.sourceforge.net;
Fri, 18 Jul 2014 15:45:11 +0000
Received: by mail-ig0-f171.google.com with SMTP id l13so733904iga.16
for <bitcoin-development@lists.sourceforge.net>;
Fri, 18 Jul 2014 08:45:05 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.42.39.142 with SMTP id h14mr9059708ice.32.1405698305529;
Fri, 18 Jul 2014 08:45:05 -0700 (PDT)
Received: by 10.50.161.137 with HTTP; Fri, 18 Jul 2014 08:45:05 -0700 (PDT)
In-Reply-To: <CANEZrP3fA3gZ5u6yViBZpdTYxyFvZT=uOTDEnL797OueXf-16g@mail.gmail.com>
References: <CAPg+sBiTURdRAZbyk3guF5YzAAQebo8yY_TuXHUKYDEdLjDUdQ@mail.gmail.com>
<CANEZrP3fA3gZ5u6yViBZpdTYxyFvZT=uOTDEnL797OueXf-16g@mail.gmail.com>
Date: Fri, 18 Jul 2014 17:45:05 +0200
Message-ID: <CAPg+sBh1sy1UynfXk284KHbBb6rEowTb7fentBBA+CkYWLdaGg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
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: 1X8ALO-0002E9-Qc
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Small update to BIP 62
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: Fri, 18 Jul 2014 15:45:11 -0000
On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn <mike@plan99.net> wrote:
> The rationale doesn't seem to apply to rule #4, what's so special about that
> one?
Nothing really. If it's controversial in any way, I'm fine with
changing that. It's just one those things that nobody needs, nobody
uses, has never been standard, and shouldn't have been possible in the
first place IMHO. Given that, it's easier to just make it a consensus
rule.
> Although I agree not having to support all of DER is nice, in practice I
> think all implementations do and libraries to parse DER are widespread.
> Given that the last time we modified tx rules without bumping version
> numbers we managed to break the only functioning iPhone client, I've become
> a big fan of backwards compatibility: seems the default choice should be to
> preserve compatibility over technical niceness until the old versions have
> been fully phased out.
I'm not comfortable with dropping OpenSSL-based signature parsing
until we have well-defined rules about which encodings are valid. At
this point I'm not even convinced we *know* about all possible ways to
modify signature encodings without invalidating them.
But perhaps we should investigate how many non-DER signatures still
make it into blocks first...
--
Pieter
|
