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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Vb8TJ-0007NN-UZ
for bitcoin-development@lists.sourceforge.net;
Tue, 29 Oct 2013 12:32:33 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vb8TJ-0002ji-0g
for bitcoin-development@lists.sourceforge.net;
Tue, 29 Oct 2013 12:32:33 +0000
Received: by mail-ob0-f175.google.com with SMTP id wm4so5057618obc.20
for <bitcoin-development@lists.sourceforge.net>;
Tue, 29 Oct 2013 05:32:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.34.194 with SMTP id b2mr18769158obj.41.1383049947159;
Tue, 29 Oct 2013 05:32:27 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Tue, 29 Oct 2013 05:32:27 -0700 (PDT)
In-Reply-To: <7a22afbd-ad30-4748-8c88-9a1eda3e2fe9@email.android.com>
References: <274a1888-276c-4aa6-a818-68f548fbe0fa@me.com>
<9DCDB8F6-E3B2-426B-A41E-087E66B3821A@gmail.com>
<526B45DB.2030200@jerviss.org>
<CABsx9T2OMA_u=S9yUh2j78QDuCDUorYctktuixjwAjqc6neW=Q@mail.gmail.com>
<526DD18A.7060201@jerviss.org> <l4lajm$3ga$1@ger.gmane.org>
<CAAS2fgSuL4f9Sdg2CyK-EuCKK04gD98zHDoKFyTg_Fp_cNiz=A@mail.gmail.com>
<CABsx9T3p6KFc8FiOgBwLtQsmkETE_iUbMhO47pS7J3hi3a9_4w@mail.gmail.com>
<CANEZrP1teOnb=Gt_Nybh0jfQopK06Ps34Hy73OxOpHwuz-iZig@mail.gmail.com>
<20131029101452.GA15808@savin>
<7a22afbd-ad30-4748-8c88-9a1eda3e2fe9@email.android.com>
Date: Tue, 29 Oct 2013 13:32:27 +0100
X-Google-Sender-Auth: m1VxsYQkVWa_sB_VUcpBjD6im4s
Message-ID: <CANEZrP2cu7WJs2TbrFxFibwAHDVbxb7EJQ3mOrVs+ZQm-uU1LQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c2275ecea7d204e9e0688a
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
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: petertodd.org]
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: 1Vb8TJ-0002ji-0g
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Feedback requested: "reject" p2p message
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: Tue, 29 Oct 2013 12:32:34 -0000
--001a11c2275ecea7d204e9e0688a
Content-Type: text/plain; charset=UTF-8
Yes, exactly. That's the point. As you well know I think the whole
soft-fork mechanism is wrong and should not be used. If the rules change,
your node is *supposed* to end up on a chain fork and trigger an alert to
you, that's pretty much the whole purpose of Bitcoin's design. Undermining
that security model is problematic.
On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd <pete@petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> Peter Todd <pete@petertodd.org> wrote:
> >On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:
> >> For block 0x11 again shall there be a separate code for "block is
> >from the
> >> future"? We don't want to lose the nVersion field to people just
> >using it
> >> for nonsense, so does it make sense to reject blocks that claim to be
> >v2 or
> >> v3?
> >
> >That would prevent us from using nVersion as a soft-forking mechanism.
>
> Actually, that statement didn't go far enough: rejecting blocks with
> nVersions that you don't expect is a hard fork.
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.0.9
>
> iQFQBAEBCAA6BQJSb544MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfuGCADHB+5WZ3oSRCCYgId+
> 5c4rxZHjjmXXIVOlXySjoRQ20JUnGbkUqN057VlutYbWaGV7OqR0oQyzh0LGpMdL
> BU9hg8XoHbyIvA0WhCfEJvFzkwseN8Ac77UxtV3leBpBkSzjqlMS9QBGU6L5rw2U
> uo8Sd7bQaqkadOPode3MMWDtmmqAZaj2dN02w/8C1rRna3SrbYRVYbaVAuN9yREO
> 99DOGEM2V7ni+eo4sQoxP2jf8vmNzy1EuQH8v1OloPgcpxl/GkLVXzQh4ZfO1ApE
> UVKBo93oT34Tce9LwZy+k8XpeCvBRJ/+QwsbAAgdVYKr8KmRcAW4oR2KN7Y0jjq4
> 44xU
> =OaON
> -----END PGP SIGNATURE-----
>
>
--001a11c2275ecea7d204e9e0688a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes, exactly. That's the point. As you well know I thi=
nk the whole soft-fork mechanism is wrong and should not be used. If the ru=
les change, your node is *supposed* to end up on a chain fork and trigger a=
n alert to you, that's pretty much the whole purpose of Bitcoin's d=
esign. Undermining that security model is problematic.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Oct 2=
9, 2013 at 12:38 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"mailto:pet=
e@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<div class=3D"im"><br>
<br>
<br>
Peter Todd <<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>=
> wrote:<br>
>On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:<br>
>> For block 0x11 again shall there be a separate code for "bloc=
k is<br>
>from the<br>
>> future"? We don't want to lose the nVersion field to peop=
le just<br>
>using it<br>
>> for nonsense, so does it make sense to reject blocks that claim to=
be<br>
>v2 or<br>
>> v3?<br>
><br>
>That would prevent us from using nVersion as a soft-forking mechanism.<=
br>
<br>
</div>Actually, that statement didn't go far enough: rejecting blocks w=
ith nVersions that you don't expect is a hard fork.<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: APG v1.0.9<br>
<br>
iQFQBAEBCAA6BQJSb544MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8<br>
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfuGCADHB+5WZ3oSRCCYgId+<br>
5c4rxZHjjmXXIVOlXySjoRQ20JUnGbkUqN057VlutYbWaGV7OqR0oQyzh0LGpMdL<br>
BU9hg8XoHbyIvA0WhCfEJvFzkwseN8Ac77UxtV3leBpBkSzjqlMS9QBGU6L5rw2U<br>
uo8Sd7bQaqkadOPode3MMWDtmmqAZaj2dN02w/8C1rRna3SrbYRVYbaVAuN9yREO<br>
99DOGEM2V7ni+eo4sQoxP2jf8vmNzy1EuQH8v1OloPgcpxl/GkLVXzQh4ZfO1ApE<br>
UVKBo93oT34Tce9LwZy+k8XpeCvBRJ/+QwsbAAgdVYKr8KmRcAW4oR2KN7Y0jjq4<br>
44xU<br>
=3DOaON<br>
-----END PGP SIGNATURE-----<br>
<br>
</blockquote></div><br></div>
--001a11c2275ecea7d204e9e0688a--
|
