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
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
|
Return-Path: <me@thomaskerin.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5E6F3B55
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 14:27:54 +0000 (UTC)
X-Greylist: delayed 00:08:50 by SQLgrey-1.7.6
Received: from thomaskerin.io (static.204.212.9.5.clients.your-server.de
[5.9.212.204])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8535D310
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 14:27:52 +0000 (UTC)
Received: from [10.137.3.15] (chomsky.torservers.net [77.247.181.162])
by thomaskerin.io (Postfix) with ESMTPSA id 2536111981094;
Wed, 16 Nov 2016 14:19:00 +0000 (UTC)
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
<CADJgMzunxU2-7Z_ZPafNY4BPRu0x9oeh6v2dg0nUYqxJbXeGYA@mail.gmail.com>
<33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org>
<CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
<A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
From: Thomas Kerin <me@thomaskerin.io>
Message-ID: <e86b5b85-591d-5342-6a75-3ebd501f1789@thomaskerin.io>
Date: Wed, 16 Nov 2016 14:18:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
Content-Type: multipart/alternative;
boundary="------------AC73D1ED2AFEEA48DAF61F37"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Wed, 16 Nov 2016 14:27:54 -0000
This is a multi-part message in MIME format.
--------------AC73D1ED2AFEEA48DAF61F37
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
BIP30 actually was given similar treatment after a reasonable amount of
time had passed.
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392
You are also missing BIP50: 'March 2013 Chain For Post-Mortem', which
neither benefited nor improved bitcoin, but did document an event for
posterity.
This is not a hard fork. Removing ISM just means we've committed to
those soft-forks only locking into the chain we use now.
On 11/16/2016 01:58 PM, Eric Voskuil via bitcoin-dev wrote:
> This sort of statement represents one consequence of the
> aforementioned bad precedent.
>
> Are checkpoints good now? Are hard forks okay now?
>
> What is the maximum depth of a reorg allowed by this non-machine
> consensus?
>
> Shouldn't we just define a max depth so that all cruft deeper than
> that can just be discarded on a regular basis?
>
> Why are there activation heights defined by this hard fork if it's not
> possible to reorg back to them?
>
> The "BIP" is neither a Proposal (it's been decided, just documenting
> for posterity), nor an Improvement (there is no actual benefit, just
> some tidying up in the notoriously obtuse satoshi code base), nor
> Bitcoin (a hard fork defines an alt coin, so from Aug 4 forward it has
> been CoreCoin).
>
> e
>
> On Nov 16, 2016, at 5:29 AM, Jameson Lopp <jameson.lopp@gmail.com
> <mailto:jameson.lopp@gmail.com>> wrote:
>
>> Since "buried deployments" are specifically in reference to
>> historical consensus changes, I think the question is more one of
>> human consensus than machine consensus. Is there any disagreement
>> amongst Bitcoin users that BIP34 activated at block 227931, BIP65
>> activated at block 388381, and BIP66 activated at block 363725?
>> Somehow I doubt it.
>>
>> It seems to me that this change is merely cementing into place a few
>> attributes of the blockchain's history that are not in dispute.
>>
>> - Jameson
>>
>> On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>
>> Actually this does nothing to provide justification for this
>> consensus rule change. It is just an attempt to deflect criticism
>> from the fact that it is such a change.
>>
>> e
>>
>> > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak@gmail.com
>> <mailto:btcdrak@gmail.com>> wrote:
>> >
>> > I think this is already covered in the BIP text:-
>> >
>> > "As of November 2016, the most recent of these changes (BIP 65,
>> > enforced since December 2015) has nearly 50,000 blocks built on
>> top of
>> > it. The occurrence of such a reorg that would cause the activati=
ng
>> > block to be disconnected would raise fundamental concerns about =
the
>> > security assumptions of Bitcoin, a far bigger issue than any
>> > non-backwards compatible change.
>> >
>> > So while this proposal could theoretically result in a consensus=
>> > split, it is extremely unlikely, and in particular any such
>> > circumstances would be sufficiently damaging to the Bitcoin
>> network to
>> > dwarf any concerns about the effects of this proposed change."
>> >
>> >
>> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
>> > <bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>> >> NACK
>> >>
>> >> Horrible precedent (hardcoding rule changes based on the
>> assumption that
>> >> large forks indicate a catastrophic failure), extremely poor
>> process
>> >> (already shipped, now the discussion), and not even a material
>> performance
>> >> optimization (the checks are avoidable once activated until a
>> sufficiently
>> >> deep reorg deactivates them).
>> >>
>> >> e
>> >>
>> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
>> >> <bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Recently Bitcoin Core merged a simplification to the consensus
>> rules
>> >> surrounding deployment of BIPs 34, 66, and 65
>> >> (https://github.com/bitcoin/bitcoin/pull/8391
>> <https://github.com/bitcoin/bitcoin/pull/8391>), and though the
>> change is a
>> >> minor one, I thought it was worth documenting the rationale in
>> a BIP for
>> >> posterity.
>> >>
>> >> Here's the abstract:
>> >>
>> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated
>> via miner
>> >> signaling in block version numbers. Now that the chain has
>> long since passed
>> >> the blocks at which those consensus rules have triggered, we
>> can (as a
>> >> simplification and optimization) replace the trigger mechanism
>> by caching
>> >> the block heights at which those consensus rules became enforce=
d.
>> >>
>> >> The full draft can be found here:
>> >>
>> >>
>> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-burie=
d-deployments.mediawiki
>> <https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buri=
ed-deployments.mediawiki>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>> >>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>> >>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------AC73D1ED2AFEEA48DAF61F37
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
BIP30 actually was given similar treatment after a reasonable amount
of time had passed. <br>
<a class="moz-txt-link-freetext" href="https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392">https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392</a><br>
<br>
You are also missing BIP50: 'March 2013 Chain For Post-Mortem',
which neither benefited nor improved bitcoin, but did document an
event for posterity. <br>
<br>
This is not a hard fork. Removing ISM just means we've committed to
those soft-forks only locking into the chain we use now. <br>
<br>
<div class="moz-cite-prefix">On 11/16/2016 01:58 PM, Eric Voskuil
via bitcoin-dev wrote:<br>
</div>
<blockquote
cite="mid:A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<div>This sort of statement represents one consequence of the
aforementioned bad precedent.</div>
<div><br>
</div>
<div>Are checkpoints good now? Are hard forks okay now?</div>
<div><br>
</div>
<div>What is the maximum depth of a reorg allowed by this
non-machine consensus?</div>
<div><br>
</div>
<div>Shouldn't we just define a max depth so that all cruft deeper
than that can just be discarded on a regular basis?</div>
<div><br>
</div>
<div>Why are there activation heights defined by this hard fork if
it's not possible to reorg back to them?</div>
<div><br>
</div>
<div>The "BIP" is neither a Proposal (it's been decided, just
documenting for posterity), nor an Improvement (there is no
actual benefit, just some tidying up in the notoriously obtuse
satoshi code base), nor Bitcoin (a hard fork defines an alt
coin, so from Aug 4 forward it has been CoreCoin).</div>
<div><br>
</div>
<div>e</div>
<div><br>
On Nov 16, 2016, at 5:29 AM, Jameson Lopp <<a
moz-do-not-send="true" href="mailto:jameson.lopp@gmail.com">jameson.lopp@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>Since "buried deployments" are specifically in
reference to historical consensus changes, I think the
question is more one of human consensus than machine
consensus. Is there any disagreement amongst Bitcoin
users that BIP34 activated at block <span
class="gmail-blob-code-inner"><span
class="gmail-pl-c1">227931,</span></span> BIP65
activated at block <span class="gmail-blob-code-inner"><span
class="gmail-pl-c1">388381, and BIP66 activated at
block </span></span><span
class="gmail-blob-code-inner"><span
class="gmail-pl-c1">363725? Somehow I doubt it.<br>
<br>
</span></span></div>
<span class="gmail-blob-code-inner"><span
class="gmail-pl-c1">It seems to me that this change is
merely cementing into place a few attributes of the
blockchain's history that are not in dispute.<br>
<br>
</span></span></div>
<span class="gmail-blob-code-inner"><span
class="gmail-pl-c1">- Jameson<br>
</span></span></div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Nov 15, 2016 at 5:42 PM,
Eric Voskuil via bitcoin-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Actually
this does nothing to provide justification for this
consensus rule change. It is just an attempt to deflect
criticism from the fact that it is such a change.<br>
<br>
e<br>
<div class="HOEnZb">
<div class="h5"><br>
> On Nov 15, 2016, at 9:45 AM, Btc Drak <<a
moz-do-not-send="true"
href="mailto:btcdrak@gmail.com">btcdrak@gmail.com</a>>
wrote:<br>
><br>
> I think this is already covered in the BIP
text:-<br>
><br>
> "As of November 2016, the most recent of these
changes (BIP 65,<br>
> enforced since December 2015) has nearly 50,000
blocks built on top of<br>
> it. The occurrence of such a reorg that would
cause the activating<br>
> block to be disconnected would raise
fundamental concerns about the<br>
> security assumptions of Bitcoin, a far bigger
issue than any<br>
> non-backwards compatible change.<br>
><br>
> So while this proposal could theoretically
result in a consensus<br>
> split, it is extremely unlikely, and in
particular any such<br>
> circumstances would be sufficiently damaging to
the Bitcoin network to<br>
> dwarf any concerns about the effects of this
proposed change."<br>
><br>
><br>
> On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil
via bitcoin-dev<br>
> <<a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>>
wrote:<br>
>> NACK<br>
>><br>
>> Horrible precedent (hardcoding rule changes
based on the assumption that<br>
>> large forks indicate a catastrophic
failure), extremely poor process<br>
>> (already shipped, now the discussion), and
not even a material performance<br>
>> optimization (the checks are avoidable once
activated until a sufficiently<br>
>> deep reorg deactivates them).<br>
>><br>
>> e<br>
>><br>
>> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar
via bitcoin-dev<br>
>> <<a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>>
wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Recently Bitcoin Core merged a
simplification to the consensus rules<br>
>> surrounding deployment of BIPs 34, 66, and
65<br>
>> (<a moz-do-not-send="true"
href="https://github.com/bitcoin/bitcoin/pull/8391"
rel="noreferrer" target="_blank">https://github.com/bitcoin/<wbr>bitcoin/pull/8391</a>),
and though the change is a<br>
>> minor one, I thought it was worth
documenting the rationale in a BIP for<br>
>> posterity.<br>
>><br>
>> Here's the abstract:<br>
>><br>
>> Prior soft forks (BIP 34, BIP 65, and BIP
66) were activated via miner<br>
>> signaling in block version numbers. Now
that the chain has long since passed<br>
>> the blocks at which those consensus rules
have triggered, we can (as a<br>
>> simplification and optimization) replace
the trigger mechanism by caching<br>
>> the block heights at which those consensus
rules became enforced.<br>
>><br>
>> The full draft can be found here:<br>
>><br>
>> <a moz-do-not-send="true"
href="https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki"
rel="noreferrer" target="_blank">https://github.com/sdaftuar/<wbr>bips/blob/buried-deployments/<wbr>bip-buried-deployments.<wbr>mediawiki</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> bitcoin-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
>> <a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> bitcoin-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
>> <a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
>><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------AC73D1ED2AFEEA48DAF61F37--
|
