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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 432FBFD6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Feb 2016 22:15:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com
[209.85.217.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8DC08106
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Feb 2016 22:15:43 +0000 (UTC)
Received: by mail-lb0-f178.google.com with SMTP id cw1so39623524lbb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 04 Feb 2016 14:15:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=FWOKokYgOdYyPyNBc/kmXXfL1puU0yPnCgnJ7r6pbTA=;
b=QqugfeDVwWY67D8LrQUJCEwgW8wlrXTk5c+HiE94cr7fEsnEOhP3/IKdaHlvlgCTlt
kSELA6YLYPvKfYjk1hxI+oyxJ26YbNy8tcLcQdLqKQwQR4asx0OwTggsSCIN8/X3XeaR
he83KdaBeMHGCFIC/PhS3rAoFar42z24zqa6JE6h537wX37HocJTMSggs8UotepdyH26
pk/cg4D8WFLGngBc2YqS/UcoIuD8BPni2BKxieG1aRJPvPNRIk2Ffl0tuFdGZ70f8KQ6
2rxQbaihLVK1ZzWGiRKjuHfesLi+LKuyi29Wu07NtwaEmMdLxA0LGdEzRiIUjVa0BSHc
4aCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=FWOKokYgOdYyPyNBc/kmXXfL1puU0yPnCgnJ7r6pbTA=;
b=cVaXlf4upKoEjTf1XIV0EW+76y2su9i3uLnHaRsgyZQ+XbtdEzZTzk6TVtnUIhE2iQ
GJS2IA9ef+lBf3pxEilnT0IZq8QpIssv+CvEnoKX6GMFFuy/p6BQQFDArE9ZQk0/Hzcb
j/RbFjtVZ7YCkZNXemyrhO+s2o11E9W3M+7p0/a1sfoZlyKetuvK0tF7NnNnqcR6kBGL
8eVA6mgYcQvcFYSYcBRMehzixMUX8dpqowyCp5GMlSyez68x4Fb5zV9D3pICKo9u3PTC
E1HCFQiaHtT++mhYruYF1h3xlXLsE/1YVkfv4uWIQZs+WY7p1NLAQdsv+xQJHTreLeMY
aF5Q==
X-Gm-Message-State: AG10YORSraejEfAr+yBrzZx8orLjv58xzwZ9bHJ56Eo+pVer+aZ80pMFQb2vK6Ejed/ZpivabA44B40LDVl91A==
MIME-Version: 1.0
X-Received: by 10.112.132.36 with SMTP id or4mr4485132lbb.50.1454624142065;
Thu, 04 Feb 2016 14:15:42 -0800 (PST)
Received: by 10.25.79.208 with HTTP; Thu, 4 Feb 2016 14:15:41 -0800 (PST)
In-Reply-To: <CAAS2fgT_f858GFVY9RAN1skd8_9Q_T1ZFoUXCQiC3o3B+z4oXw@mail.gmail.com>
References: <f225318eddd0aadc71861f988f2f4674@xbt.hk>
<CAAS2fgT_f858GFVY9RAN1skd8_9Q_T1ZFoUXCQiC3o3B+z4oXw@mail.gmail.com>
Date: Thu, 4 Feb 2016 17:15:41 -0500
Message-ID: <CABsx9T1AdWPAtGHkhMAGtnWtthE+oienUBm0iXEfUG05S6ko-Q@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary=047d7b3a822c450c5e052af9136b
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 04 Feb 2016 22:30:16 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork bit BIP
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2016 22:15:44 -0000
--047d7b3a822c450c5e052af9136b
Content-Type: text/plain; charset=UTF-8
It is always possible I'm being dense, but I still don't understand how
this proposal makes a chain-forking situation better for anybody.
If there are SPV clients that don't pay attention to versions in block
headers, then setting the block version negative doesn't directly help
them, they will ignore it in any case.
If the worry is full nodes that are not upgraded, then a block with a
negative version number will, indeed, fork them off the the chain, in
exactly the same way a block with new hard-forking consensus rules would.
And with the same consequences (if there is any hashpower not paying
attention, then a worthless minority chain might continue on with the old
rules).
If the worry is not-upgraded SPV clients connecting to the old,
not-upgraded full nodes, I don't see how this proposed BIP helps.
I think a much better idea than this proposed BIP would be a BIP that
recommends that SPV clients to pay attention to block version numbers in
the headers that they download, and warn if there is a soft OR hard fork
that they don't know about.
It is also a very good idea for SPV clients to pay attention to timestamps
in the block headers that the receive, and to warn if blocks were generated
either much slower or faster than statistically likely. Doing that (as
Bitcoin Core already does) will mitigate Sybil attacks in general.
--
--
Gavin Andresen
--047d7b3a822c450c5e052af9136b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It is always possible I'm being dense, but I still don=
't understand how this proposal makes a chain-forking situation better =
for anybody.<div><br></div><div>If there are SPV clients that don't pay=
attention to versions in block headers, then setting the block version neg=
ative doesn't directly help them, they will ignore it in any case.</div=
><div><br></div><div>If the worry is full nodes that are not upgraded, then=
a block with a negative version number will, indeed, fork them off the the=
chain, in exactly the same way a block with new hard-forking consensus rul=
es would. And with the same consequences (if there is any hashpower not pay=
ing attention, then a worthless minority chain might continue on with the o=
ld rules).</div><div><br></div><div>If the worry is not-upgraded SPV client=
s connecting to the old, not-upgraded full nodes, I don't see how this =
proposed BIP helps.</div><div><br></div><div>I think a much better idea tha=
n this proposed BIP would be a BIP that recommends that SPV clients to pay =
attention to block version numbers in the headers that they download, and w=
arn if there is a soft OR hard fork that they don't know about.</div><d=
iv><br></div><div>It is also a very good idea for SPV clients to pay attent=
ion to timestamps in the block headers that the receive, and to warn if blo=
cks were generated either much slower or faster than statistically likely. =
Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in ge=
neral.</div><div><br></div><div class=3D"gmail_extra">-- <br><div class=3D"=
gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>--<br>Gavin An=
dresen<br></div><div><br></div></div></div></div></div>
</div></div>
--047d7b3a822c450c5e052af9136b--
|
