summaryrefslogtreecommitdiff
path: root/df/36c2286edcf82eaf7a8351b5770a39df997740
blob: 93363e92a90442fc2c8c97e5ea7cbb5b53d649e0 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1VbL64-0008BC-Ms
	for bitcoin-development@lists.sourceforge.net;
	Wed, 30 Oct 2013 02:01:24 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.170 as permitted sender)
	client-ip=209.85.212.170; envelope-from=gavinandresen@gmail.com;
	helo=mail-wi0-f170.google.com; 
Received: from mail-wi0-f170.google.com ([209.85.212.170])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VbL62-000050-O7
	for bitcoin-development@lists.sourceforge.net;
	Wed, 30 Oct 2013 02:01:24 +0000
Received: by mail-wi0-f170.google.com with SMTP id ex4so3480816wid.1
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 29 Oct 2013 19:01:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.188.164 with SMTP id gb4mr528089wic.52.1383098476434;
	Tue, 29 Oct 2013 19:01:16 -0700 (PDT)
Received: by 10.194.156.163 with HTTP; Tue, 29 Oct 2013 19:01:16 -0700 (PDT)
In-Reply-To: <CANEZrP2cu7WJs2TbrFxFibwAHDVbxb7EJQ3mOrVs+ZQm-uU1LQ@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>
Date: Wed, 30 Oct 2013 12:01:16 +1000
Message-ID: <CABsx9T25sqq5ps+ePgc+tH+ns8ygahpYztgga0DuqgoQj9tpzQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a11c25c9e609aee04e9ebb507
X-Spam-Score: -0.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
	(gavinandresen[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-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
	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: plan99.net]
X-Headers-End: 1VbL62-000050-O7
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 02:01:24 -0000

--001a11c25c9e609aee04e9ebb507
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 29, 2013 at 10:32 PM, Mike Hearn <mike@plan99.net> wrote:

> 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.
>

But if you are getting soft-forked recent versions of the reference
implementation WILL alert you; see this code in main.cpp:

        if (nUpgraded > 100/2)
            strMiscWarning = _("Warning: This version is obsolete, upgrade
required!");

That is, if more than half of the last 100 blocks are up-version, warn.
 block.version is part of the block header, so SPV clients can (and
probably should) do the same.

There are also warnings if you are forked, and, most recently, warnings if
there is a high-work alternative fork.

-- 
--
Gavin Andresen

--001a11c25c9e609aee04e9ebb507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Oct 29, 2013 at 10:32 PM, Mike Hearn <span dir=3D"=
ltr">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.n=
et</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex">
<div dir=3D"ltr">Yes, exactly. That&#39;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&#39;s pretty much the whole purpose of Bitcoin&#39;s d=
esign. Undermining that security model is problematic.</div>
</blockquote><div><br></div><div>But if you are getting soft-forked recent =
versions of the reference implementation WILL alert you; see this code in m=
ain.cpp:</div><div><br></div><div><div>=A0 =A0 =A0 =A0 if (nUpgraded &gt; 1=
00/2)</div>
<div>=A0 =A0 =A0 =A0 =A0 =A0 strMiscWarning =3D _(&quot;Warning: This versi=
on is obsolete, upgrade required!&quot;);</div></div><div><br></div><div>Th=
at is, if more than half of the last 100 blocks are up-version, warn. =A0bl=
ock.version is part of the block header, so SPV clients can (and probably s=
hould) do the same.</div>
<div><br></div><div>There are also warnings if you are forked, and, most re=
cently, warnings if there is a high-work alternative fork.</div><div><br></=
div></div>-- <br>--<br>Gavin Andresen<br>
</div></div>

--001a11c25c9e609aee04e9ebb507--