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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
|
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 5CCA91191
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Feb 2016 10:20:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com
[209.85.213.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C4EA132
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Feb 2016 10:20:29 +0000 (UTC)
Received: by mail-vk0-f43.google.com with SMTP id c3so7200561vkb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 05 Feb 2016 02:20:29 -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=Yx/abHP+zcPvvk1Jlt3TBMmDhQRV/D+P4oxSByELlcg=;
b=PFLdhRkE65+2kp1OdqajOklxFHewbd10jm3xCWAxqy/99NsqA/qu2yCV/19RPwKC6H
aakXSt4TJHblyNp63jpt4nCZtb2kb+JO/UlO57kuEckdCPBWEIXpGMvS1kH+cPNKnvFM
zMH5pHxvuAR3DITvhdXxr4Sa0K7Or2+AHsLDvze7pRdVSmU+68M2rMmAK14qB5QNW1ZK
+aWGBpetUSJyoU5pfKhzsCLG+2M7DwBO9Pd6ZeWL4u5tJHIDge4kmRlmUJZauO202QmA
gY3b4yyMGb28V/6GLTqllRp4QEJZT8FuzVjL6RoDNPswpWkeia4hjnX2O3rE4ifpZ+V9
qOZA==
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=Yx/abHP+zcPvvk1Jlt3TBMmDhQRV/D+P4oxSByELlcg=;
b=Dh3gg1FamU6xWsQkVMKqBKZNyjgUZ28F3qQ6Tr69KjdSx24/RMGF8f5sOi4nqglyrJ
9zNjwUceLqaPLbjcF0ZBBZWvG0I/rBzaHd9CC2Cw+zc4YuJN6aVcGnlZKPmXIXlVWNwz
H3y4G0ljETrafowfksEwNwynBGoOhrfQYgeyqY7rdlqmYHVzKmwAaJnXdmdkvcL69QHA
ZFpWrgphwEemrWJlNOMrgL1y0ZGkTOUb/WeEk4rYeyzohHAHlRPDR8gzrnNCGtwpr/Ja
9Tl7RSNEqiWiC77u5uxGxik9NPERPT2AlRauo420sOsFQrQJ3XB/ApE5uTPVyTiLJU3o
k96A==
X-Gm-Message-State: AG10YORWr7fdaXgqJtsTXUV2ZKJ/qLnDCr7X+qLf87AQyE4jHye8/rdLp1CxlsGN8fbgap0mdG8Lr7/dMUJgyw==
MIME-Version: 1.0
X-Received: by 10.31.159.136 with SMTP id i130mr8949940vke.144.1454667628332;
Fri, 05 Feb 2016 02:20:28 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Fri, 5 Feb 2016 02:20:28 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Fri, 5 Feb 2016 02:20:28 -0800 (PST)
In-Reply-To: <201602041829.13459.luke@dashjr.org>
References: <f225318eddd0aadc71861f988f2f4674@xbt.hk>
<201602041829.13459.luke@dashjr.org>
Date: Fri, 5 Feb 2016 11:20:28 +0100
Message-ID: <CABm2gDp+mm75+g2gvZmzO_+BP1+qG0yo9Y80tTdNxAsxNE6j_Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a1142ed9640dfdf052b0333c4
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 10:20:30 -0000
--001a1142ed9640dfdf052b0333c4
Content-Type: text/plain; charset=UTF-8
On Feb 4, 2016 19:29, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote:
> > ABSTRACT
> >
> > This document specifies a proposed change to the semantics of the sign
> > bit of the "version" field in Bitcoin block headers, as a mechanism to
> > indicate a hardfork is deployed.
>
> Disagree with treating the "version" field as a number, in BIP 9 or this
BIP
> which reinterpret it as a bit vector.
I don't interpret this as "treating version bits as a number" it is just
being explained which bit we're talking about. Could you propose some
concrete rephrasing instead of leaving the task of somehow solving this
vague and subtle concern to the author?
> > FLAG BLOCK Any planned hardfork must have one and only one flag block
> > which is the "point of no return". To ensure monotonicity, flag block
> > should be determined by block height, or as the first block with
> > GetMedianTimePast() greater than a threshold. Other mechanisms could be
> > difficult for SPV nodes to follow. The height/time threshold could be a
> > predetermined value or relative to other events (e.g. 10000 blocks / 100
> > days after 95% of miner support). The exact mechanism is out of the
> > scope of this BIP. No matter what mechanism is used, the threshold is
> > consensus critical. It must be publicly verifiable with only blockchain
> > data, and preferably SPV-friendly (i.e. verifiable with block headers
> > only, without downloading any transaction).
>
> With the current codebase, it is significantly easier to trigger on the
block
> timestamp rather than its height or median-time-past. Using either of the
> latter would require refactoring of CBlockIndex. As a hard-fork, even if
the
> rules are ineffective for a few blocks following the forking point, using
the
> hardfork version bit in this BIP would still ensure a clean break. While I
> agree that median-time-past and height are superior methods that ought to
be
> used for hardforks, an emergency hardfork may need to avoid them for
> simplicity, and I don't think they need to be mandated as such in this
BIP.
I very much disagree with "significant" and in any case it depends on the
hardfork: the changes required can still be quite minimal in all cases and
it should never be a problem, even for emergency hardforks. In emergency,
we could for example just a new global (we have many already anyway),
although activeChain.tip () is already there and one can simply get the
last height or median time from there.
> > VERSION BITS This proposal is also compatible with the BIP9. The version
> > bits mechanism could be employed to measure miner support towards a
> > hardfork proposal, and to determine the height or time threshold of the
> > flag block. Also, miners of the flag block may still cast votes for
> > other concurrent softfork or hardfork proposals as normal.
>
> Rather not imply BIP 9 should be used for hardforks, or that miners have
any
> voice in the decision. This is already a serious misconception.
This is consistent with bip99, which recommends bip9 for deploying
uncontroversial hardforks.
> > POINT OF NO RETURN After the flag block is generated, a miner may
> > support either the original rules or the new rules, but not both. It is
> > not possible for miners in one fork to attack or overtake the other fork
> > without giving up the mining reward of their preferred fork.
>
> This is not actually desirable, and would suggest a possible reason *not*
to
> comply with this BIP. A legitimate hardfork would never have two continued
> sets of rules for miners to choose from.
Controversial hardforks (as defined bip9) always have the potential to
create two chains that survive for unbounded amounts of time (maybe
forever) as discussed in one of the few threads of the bitcoin discuss
mailing list.
Of course, BIP99 cannot say anything general about the "legitimacy" of all
controversial hardforks since ASIC-reset hardforks, for example, are
controversial hardforks by definition in the context of bip99 (and the
definitions in bip99 seem to apply to this bip). BIP99 can only warn about
the dangers and risks of controversial hardforks but at some point (let's
hope never) a controversial hardfork may be required to save the system
from some evil (say, evil miners blacklisting via softforking out the
miners that don't blacklist or something) and that controversial hardfork
would be legitimate (at least to the eyes of some).
--001a1142ed9640dfdf052b0333c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Feb 4, 2016 19:29, "Luke Dashjr via bitcoin-dev" <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<br>
><br>
> On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote=
:<br>
> > ABSTRACT<br>
> ><br>
> > This document specifies a proposed change to the semantics of the=
sign<br>
> > bit of the "version" field in Bitcoin block headers, as=
a mechanism to<br>
> > indicate a hardfork is deployed.<br>
><br>
> Disagree with treating the "version" field as a number, in B=
IP 9 or this BIP<br>
> which reinterpret it as a bit vector.</p>
<p dir=3D"ltr">I don't interpret this as "treating version bits as=
a number" it is just being explained which bit we're talking abou=
t. Could you propose some concrete rephrasing instead of leaving the task o=
f somehow solving this vague and subtle concern to the author?</p>
<p dir=3D"ltr">> > FLAG BLOCK Any planned hardfork must have one and =
only one flag block<br>
> > which is the "point of no return". To ensure monotonici=
ty, flag block<br>
> > should be determined by block height, or as the first block with<=
br>
> > GetMedianTimePast() greater than a threshold. Other mechanisms co=
uld be<br>
> > difficult for SPV nodes to follow. The height/time threshold coul=
d be a<br>
> > predetermined value or relative to other events (e.g. 10000 block=
s / 100<br>
> > days after 95% of miner support). The exact mechanism is out of t=
he<br>
> > scope of this BIP. No matter what mechanism is used, the threshol=
d is<br>
> > consensus critical. It must be publicly verifiable with only bloc=
kchain<br>
> > data, and preferably SPV-friendly (i.e. verifiable with block hea=
ders<br>
> > only, without downloading any transaction).<br>
><br>
> With the current codebase, it is significantly easier to trigger on th=
e block<br>
> timestamp rather than its height or median-time-past. Using either of =
the<br>
> latter would require refactoring of CBlockIndex. As a hard-fork, even =
if the<br>
> rules are ineffective for a few blocks following the forking point, us=
ing the<br>
> hardfork version bit in this BIP would still ensure a clean break. Whi=
le I<br>
> agree that median-time-past and height are superior methods that ought=
to be<br>
> used for hardforks, an emergency hardfork may need to avoid them for<b=
r>
> simplicity, and I don't think they need to be mandated as such in =
this BIP.</p>
<p dir=3D"ltr">I very much disagree with "significant" and in any=
case it depends on the hardfork: the changes required can still be quite m=
inimal in all cases and it should never be a problem, even for emergency ha=
rdforks. In emergency, we could for example just a new global (we have many=
already anyway), although activeChain.tip () is already there and one can =
simply get the last height or median time from there.</p>
<p dir=3D"ltr">> > VERSION BITS This proposal is also compatible with=
the BIP9. The version<br>
> > bits mechanism could be employed to measure miner support towards=
a<br>
> > hardfork proposal, and to determine the height or time threshold =
of the<br>
> > flag block. Also, miners of the flag block may still cast votes f=
or<br>
> > other concurrent softfork or hardfork proposals as normal.<br>
><br>
> Rather not imply BIP 9 should be used for hardforks, or that miners ha=
ve any<br>
> voice in the decision. This is already a serious misconception.</p>
<p dir=3D"ltr">This is consistent with bip99, which recommends bip9 for dep=
loying uncontroversial hardforks.</p>
<p dir=3D"ltr">> > POINT OF NO RETURN After the flag block is generat=
ed, a miner may<br>
> > support either the original rules or the new rules, but not both.=
It is<br>
> > not possible for miners in one fork to attack or overtake the oth=
er fork<br>
> > without giving up the mining reward of their preferred fork.<br>
><br>
> This is not actually desirable, and would suggest a possible reason *n=
ot* to<br>
> comply with this BIP. A legitimate hardfork would never have two conti=
nued<br>
> sets of rules for miners to choose from.</p>
<p dir=3D"ltr">Controversial hardforks (as defined bip9) always have the po=
tential to create two chains that survive for unbounded amounts of time (ma=
ybe forever) as discussed in one of the few threads of the bitcoin discuss =
mailing list.<br>
Of course, BIP99 cannot say anything general about the "legitimacy&quo=
t; of all controversial hardforks since ASIC-reset hardforks, for example, =
are controversial hardforks by definition in the context of bip99 (and the =
definitions in bip99 seem to apply to this bip). BIP99 can only warn about =
the dangers and risks of controversial hardforks but at some point (let'=
;s hope never) a controversial hardfork may be required to save the system =
from some evil (say, evil miners blacklisting via softforking out the miner=
s that don't=C2=A0 blacklist or something) and that controversial hardf=
ork would be legitimate (at least to the eyes of some). </p>
--001a1142ed9640dfdf052b0333c4--
|
