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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VbR59-0005lL-7j
for bitcoin-development@lists.sourceforge.net;
Wed, 30 Oct 2013 08:24:51 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.43 as permitted sender)
client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f43.google.com;
Received: from mail-oa0-f43.google.com ([209.85.219.43])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VbR58-0006bP-Ef
for bitcoin-development@lists.sourceforge.net;
Wed, 30 Oct 2013 08:24:51 +0000
Received: by mail-oa0-f43.google.com with SMTP id m1so1115218oag.30
for <bitcoin-development@lists.sourceforge.net>;
Wed, 30 Oct 2013 01:24:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.68.135 with SMTP id w7mr3301002oet.9.1383121484869; Wed,
30 Oct 2013 01:24:44 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Wed, 30 Oct 2013 01:24:44 -0700 (PDT)
In-Reply-To: <CABsx9T25sqq5ps+ePgc+tH+ns8ygahpYztgga0DuqgoQj9tpzQ@mail.gmail.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>
<CANEZrP2cu7WJs2TbrFxFibwAHDVbxb7EJQ3mOrVs+ZQm-uU1LQ@mail.gmail.com>
<CABsx9T25sqq5ps+ePgc+tH+ns8ygahpYztgga0DuqgoQj9tpzQ@mail.gmail.com>
Date: Wed, 30 Oct 2013 09:24:44 +0100
X-Google-Sender-Auth: qIsJdxPoaeHkHExe1Ql2rumhgX8
Message-ID: <CANEZrP0fU3M3o4ZgBormcuRvkipM0tjNG+StA_QC90UbcpxdGA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134c4c2c979bd04e9f110d1
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: 1VbR58-0006bP-Ef
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: Wed, 30 Oct 2013 08:24:51 -0000
--001a1134c4c2c979bd04e9f110d1
Content-Type: text/plain; charset=UTF-8
> But if you are getting soft-forked recent versions of the reference
> implementation WILL alert you; see this code in main.cpp:
>
Perhaps I'm confused about how we're using the term soft fork. My
understanding is that this is where a new upgrade is designed to look valid
to old nodes, and if you don't upgrade you rely on the miner majority to
get you "back on track". For instance, P2SH was done this way - old nodes
that didn't upgrade during that transition believed all spends of P2SH
outputs were valid, even those spending someone elses coins.
In this case, the code you cite won't do anything because your client will
never reject a block during a soft-forking upgrade, even if it does
something that's supposed to be invalid or nonsensical.
If a new block version changes the serialization format or script language
or SIGHASH rules such that old clients reject the block, then they will end
up on a hard fork and the alerting code will trigger, which is correct and
as it should be.
--001a1134c4c2c979bd04e9f110d1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">
<div>But if you are getting soft-forked recent versions of the reference im=
plementation WILL alert you; see this code in main.cpp:</div></div></div></=
div></blockquote><div><br></div><div>Perhaps I'm confused about how we&=
#39;re using the term soft fork. My understanding is that this is where a n=
ew upgrade is designed to look valid to old nodes, and if you don't upg=
rade you rely on the miner majority to get you "back on track". F=
or instance, P2SH was done this way - old nodes that didn't upgrade dur=
ing that transition believed all spends of P2SH outputs were valid, even th=
ose spending someone elses coins.</div>
<div><br></div><div>In this case, the code you cite won't do anything b=
ecause your client will never reject a block during a soft-forking upgrade,=
even if it does something that's supposed to be invalid or nonsensical=
.</div>
<div><br></div><div>If a new block version changes the serialization format=
or script language or SIGHASH rules such that old clients reject the block=
, then they will end up on a hard fork and the alerting code will trigger, =
which is correct and as it should be.</div>
</div></div></div>
--001a1134c4c2c979bd04e9f110d1--
|
