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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 674AEE86
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Feb 2016 09:58:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com
[209.85.213.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F08E4A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Feb 2016 09:58:37 +0000 (UTC)
Received: by mail-vk0-f51.google.com with SMTP id e6so53275546vkh.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 05 Feb 2016 01:58:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=EQufEkkCZ2+6QLiPVia0quG2tfzJj+l4QHBwCe8qqho=;
b=xXSiOmjlLEnYq2+mgwesv2VxzCzODGdcKRWoibkAXOtNWhAD7ljSY+6cC4FO+D/+AC
5sgl5ipGZUjktuuSaltz6KmMbWsnLpTZ25kWezjQefMwK+0DEZBCcNQYhBc3o9UwZGZk
7w8hdXrcSRsIGjp723OnRj8MpheF9KGXPYCFQCrgz38qNRpmHR1NhufjF+OjuCqswSYi
CkwZjic9YbwmpjSAYLyAticlMWLH912mXsP/gDgg+5+V/45HOwxRU1JAtEaJ61882ZGK
Xe6brUVjhFRxDwMfTho8jgwJJKTAcWVYqrOHx4YaV6BIHjDt3rEzUxjNQHFCaQd9NsqV
fQEA==
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=EQufEkkCZ2+6QLiPVia0quG2tfzJj+l4QHBwCe8qqho=;
b=cCK9PrQdyqwvOCilym40vQ3bmFZB4hvRWXTGjo4eLoIa+ClWSZndTYxm0zjmxM3Q4Q
fZXTjTXXj3wP4Mu7SgS4KirTMmMCg/ldzGFHB8W7aIovHHcnsr1o21OA7ozEyh1IJUDC
an1M+29vnGnI+J/G3cdoUoFCwE8F/gSRFfYAtRJTNmRywuf4NiR2eoHBCbhvEIpkqYTI
F4X1tbEllNcGDHuYiAb+8g7sk6LalmM+0sEfbQWacTOeQwbc0aGQqb2TDdLpt4xZzVjN
uFUImCvnDEHEonh9QXz8w+e1tEyVfUDP6jyn3LDmuWMYcM0U07bv4J3f5XqwlaCLSMO3
/pgg==
X-Gm-Message-State: AG10YOSPCj752NlhXBv1wMVhTEa24XR7Fa/lpozfgKtvDFR0yfyGnme0xD+OA/y6hcXLVOYaSggqiV9QuBMwvg==
MIME-Version: 1.0
X-Received: by 10.31.14.195 with SMTP id 186mr8763556vko.2.1454666317076; Fri,
05 Feb 2016 01:58:37 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Fri, 5 Feb 2016 01:58:36 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Fri, 5 Feb 2016 01:58:36 -0800 (PST)
In-Reply-To: <CABsx9T1AdWPAtGHkhMAGtnWtthE+oienUBm0iXEfUG05S6ko-Q@mail.gmail.com>
References: <f225318eddd0aadc71861f988f2f4674@xbt.hk>
<CAAS2fgT_f858GFVY9RAN1skd8_9Q_T1ZFoUXCQiC3o3B+z4oXw@mail.gmail.com>
<CABsx9T1AdWPAtGHkhMAGtnWtthE+oienUBm0iXEfUG05S6ko-Q@mail.gmail.com>
Date: Fri, 5 Feb 2016 10:58:36 +0100
Message-ID: <CABm2gDpPZ6gcUncM3opPYft6+g=MH35xvboRfLaitju9DDyCxg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a1143d31218af35052b02e5b0
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
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: Fri, 05 Feb 2016 09:58:39 -0000
--001a1143d31218af35052b02e5b0
Content-Type: text/plain; charset=UTF-8
Concept ACK. I've been talking about adding this to BIP99 since before
scaling bitcoin Hong Kong, so it will be nice to have a BIP to just point
to. Also I hadn't thought about concurrent deployment of 2 hardforks, nice.
On Feb 4, 2016 23:30, "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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).
Additionally, a warning or special error could be thrown when a block is
rejected due to the hardfork bit being activated.
> 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.
Although I agree this PR should include such warning/error recommendations,
SPV nodes can't tell whether a change is a hardfork or a softfork just by
looking at the version bits, even in the case of uncontroversial hardforks
deployed with bip9 as recommended by bip99. For controversial hardforks
where bip9 should NOT be used for deployment, setting the hardfork bit is
even more important.
> 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.
This seems out of the scope of this PR.
--001a1143d31218af35052b02e5b0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Concept ACK. I've been talking about adding this to BIP9=
9 since before scaling bitcoin Hong Kong, so it will be nice to have a BIP =
to just point to. Also I hadn't thought about concurrent deployment of =
2 hardforks, nice.</p>
<p dir=3D"ltr">On Feb 4, 2016 23:30, "Gavin Andresen via bitcoin-dev&q=
uot; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>> wrote:</p>
<p dir=3D"ltr">> 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 rule=
s would. And with the same consequences (if there is any hashpower not payi=
ng attention, then a worthless minority chain might continue on with the ol=
d rules).</p>
<p dir=3D"ltr">Additionally, a warning or special error could be thrown whe=
n a block is rejected due to the hardfork bit being activated.<br></p>
<p dir=3D"ltr">> I think a much better idea than this proposed BIP would=
be a BIP that recommends that SPV clients to pay attention to block versio=
n numbers in the headers that they download, and warn if there is a soft OR=
hard fork that they don't know about.</p>
<p dir=3D"ltr">Although I agree this PR should include such warning/error r=
ecommendations, SPV nodes can't tell whether a change is a hardfork or =
a softfork just by looking at the version bits, even in the case of uncontr=
oversial hardforks deployed with bip9 as recommended by bip99. For controve=
rsial hardforks where bip9 should NOT be used for deployment, setting the h=
ardfork bit is even more important.</p>
<p dir=3D"ltr">> It is also a very good idea for SPV clients to pay atte=
ntion to timestamps in the block headers that the receive, and to warn if b=
locks were generated either much slower or faster than statistically likely=
. Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in =
general.</p>
<p dir=3D"ltr">This seems out of the scope of this PR.<br>
</p>
--001a1143d31218af35052b02e5b0--
|
