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
90
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1X8AGS-00069d-4u
for bitcoin-development@lists.sourceforge.net;
Fri, 18 Jul 2014 15:40:04 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.49 as permitted sender)
client-ip=209.85.219.49; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f49.google.com;
Received: from mail-oa0-f49.google.com ([209.85.219.49])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X8AGQ-00073C-C3
for bitcoin-development@lists.sourceforge.net;
Fri, 18 Jul 2014 15:40:03 +0000
Received: by mail-oa0-f49.google.com with SMTP id eb12so3392921oac.8
for <bitcoin-development@lists.sourceforge.net>;
Fri, 18 Jul 2014 08:39:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.70.205 with SMTP id o13mr8122951oeu.38.1405697996399;
Fri, 18 Jul 2014 08:39:56 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Fri, 18 Jul 2014 08:39:56 -0700 (PDT)
In-Reply-To: <CAPg+sBiTURdRAZbyk3guF5YzAAQebo8yY_TuXHUKYDEdLjDUdQ@mail.gmail.com>
References: <CAPg+sBiTURdRAZbyk3guF5YzAAQebo8yY_TuXHUKYDEdLjDUdQ@mail.gmail.com>
Date: Fri, 18 Jul 2014 17:39:56 +0200
X-Google-Sender-Auth: EZ4udCHkpEM0TpUU32Qju8mPqHg
Message-ID: <CANEZrP3fA3gZ5u6yViBZpdTYxyFvZT=uOTDEnL797OueXf-16g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11333df6bcacb004fe7991a3
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1X8AGQ-00073C-C3
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:40:04 -0000
--001a11333df6bcacb004fe7991a3
Content-Type: text/plain; charset=UTF-8
The rationale doesn't seem to apply to rule #4, what's so special about
that one?
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.
--001a11333df6bcacb004fe7991a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The rationale doesn't seem to apply to rule #4, what&#=
39;s so special about that one?<div><br></div><div>Although I agree not hav=
ing 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 m=
odified tx rules without bumping version numbers we managed to break the on=
ly functioning iPhone client, I've become a big fan of backwards compat=
ibility: seems the default choice should be to preserve compatibility over =
technical niceness until the old versions have been fully phased out.</div>
</div>
--001a11333df6bcacb004fe7991a3--
|
