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
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
|
Return-Path: <allen.piscitello@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B02BDAC1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jun 2015 17:24:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com
[209.85.223.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E0331DE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jun 2015 17:24:33 +0000 (UTC)
Received: by iebmu5 with SMTP id mu5so37799714ieb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jun 2015 10:24:32 -0700 (PDT)
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=JBl15Z1tBrkOZq7pfanL4kufPdyRPaBOWQfTfQwKcCA=;
b=XpkyPue6upUL6GF6hDluNIaKNcYGGG9XgsrFekJR/OtJZ7ugMiKGHKpgOzvVabu714
MJSX/5d06OGOTv2KRgFEP07biZgowvdAaVVQ/MFSQ1A9MxXHrsJ0mWz9iRnIiAU/8zbV
Reb9u8OL4X0zqK3z37KA7YmZ2+INCUmlQdEgZWaasL9Fqjld3p/UYaBslH4RTZCmfKPQ
tzTVgK0wG20fse06sU2MV+fj3Ooodba3edpRb9VT2nL0F1O9XaiuwXadT019Zpe98zn0
X9t2hEZKixX1H9ROsmWBVh91jAja/MQRDT0yXVC3NhMu+C/9McCihDsH9WYCvdCvDnRI
fJDw==
MIME-Version: 1.0
X-Received: by 10.42.238.14 with SMTP id kq14mr38845518icb.23.1435166672526;
Wed, 24 Jun 2015 10:24:32 -0700 (PDT)
Received: by 10.79.23.6 with HTTP; Wed, 24 Jun 2015 10:24:32 -0700 (PDT)
In-Reply-To: <COL402-EAS745A879FDD8D3BAB8216D7CDAF0@phx.gbl>
References: <COL402-EAS745A879FDD8D3BAB8216D7CDAF0@phx.gbl>
Date: Wed, 24 Jun 2015 12:24:32 -0500
Message-ID: <CAJfRnm64tomNUL9u-YP2SHSsi=SOx21aVNLNE8N_2EyTez8D1Q@mail.gmail.com>
From: Allen Piscitello <allen.piscitello@gmail.com>
To: Raystonn <raystonn@hotmail.com>
Content-Type: multipart/alternative; boundary=047d7bacbbccb5a4f5051946c7ab
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
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: Wed, 24 Jun 2015 17:24:34 -0000
--047d7bacbbccb5a4f5051946c7ab
Content-Type: text/plain; charset=UTF-8
This is no different than any other soft fork. Proper communication can
coordinate soft forks easily.
On Wed, Jun 24, 2015 at 12:23 PM, Raystonn <raystonn@hotmail.com> wrote:
> You really believe they would risk getting orphaned by skipping the longer
> chain, just to attempt to reduce average block size? No, that doesn't
> happen today. Laziness in leaving the default size is common. But that is
> not collusion, nor an attempt to manipulate the block sizes of other miners.
> On 24 Jun 2015 10:05 am, Mark Friedenbach <mark@friedenbach.org> wrote:
>
> They do so by not building on larger blocks
> On Jun 23, 2015 9:31 PM, "Raystonn" <raystonn@hotmail.com> wrote:
>
> No, they can lower their own block sizes. But they cannot currently lower
> the sizes of blocks mined by others. That is not the same thing by any
> stretch of the imagination.
> On 23 Jun 2015 8:50 pm, Jeff Garzik <jgarzik@gmail.com> wrote:
>
> Miners can collude today to lower the block size limit.
>
> In fact, this largely happens already out of laziness - miners often
> follow the "soft" default limit set by Bitcoin Core, to the point where you
> can chart when miners upgrade to new software:
> http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
>
>
>
> On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri.com>
> wrote:
>
> Here are refutations of the approach in BIP-100 here:
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>
> To recap BIP-100:
>
> 1) Hard form to remove static 1MB block size limit
> 2) Add new floating block size limit set to 1MB
> 3) Historical 32MB message limit remains
> 4) Hard form on testnet 9/1/2015
> 5) Hard form on main 1/11/2016
> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
> threshold by 90% of blocks
> 7) Limit increase or decrease may not exceed 2x in any one step
> 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
> scriptSig, e.g. "/BV8000000/" to vote for 8M.
> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
> most common floor (minimum) is chosen.
>
> 8MB limits doubling just under every 2 years makes a static value grow
> in a predictable manner.
>
> BIP-100 makes a static value grow (or more importantly potentially
> shrink) in an unpredictable manner based on voting mechanics that are
> untested in this capacity in the bitcoin network. Introducing a highly
> variable and untested dynamic into an already complex system is
> unnecessarily risky.
>
> For example, the largely arbitrary voting rules listed in 9 above can be
> gamed. If I control pools or have affiliates involved in pools that
> mine slightly more than 20% of blocks, I could wait until block sizes
> are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
> "/BV5000001/" for the remaining 10%. If others don't consistently vote
> for the same "/BV#/" value, vote too consistently and have their value
> thrown out as the top 20%, I could win the resize to half capacity
> "/BV5000001/" because it was the lowest repeated value not in the bottom
> 20%.
>
> I could use this to force an exodus to my sidechain/alt coin, or to
> choke out the bitcoin network. A first improvement would be to only let
> BIP-100 raise the cap and not lower it, but if I can think of a
> vulnerability off the top of my head, there will be others on the other
> side of the equation that have not been thought of. Why bother
> introducing a rube goldberg machine like voting when a simple 8mb cap
> with predictable growth gets the job done, potentially permanently?
>
>
> On 6/23/2015 9:43 PM, odinn wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 1) Hard fork not (necessarily) needed
> > 2) See Garzik's BIP 100, better (this is not meant to say "superior to
> > your stuff," but rather simply to say, "Better you should work with
> > Garzik to implement BIP-100, that would be good")
> > 3) See points 1 and 2 above
> > 4) If still reading... changes should be (as you seem to have been
> > trying to lean towards)... lean towards gradual change; hence, changes
> > that would flow from this BIP would be better off oriented in a
> > process that dies not require the "way you have done it."
> >
> > You did address that, to be fair - in your TODO, this link:
> > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> >
> > contained the following link:
> >
> > http://gavinandresen.ninja/bigger-blocks-another-way
> >
> > However, in reading that, I didn't see any meaningful statements that
> > would refute the approach in Garzik's BIP-100.
> >
> > Maybe a better way to say this is,
> >
> > Work with Jeff Garzik (which I am sure you are already having such
> > discussions in private) as well as the list discussions,
> > Move forward on BIP-100 with Garzik and other developers (not such a
> > bad plan really) and don't get caught up in XT. (If you feel you can
> > develop XT further, that is your thing but it would perhaps make you
> > lose focus, work together with other developers.)
> >
> > Relax into the process. Things will be ok.
> >
> > Respectfully,
> >
> > - -O
> >
> > On 06/22/2015 11:18 AM, Gavin Andresen wrote:
> >> I promised to write a BIP after I'd implemented
> >> increase-the-maximum-block-size code, so here it is. It also lives
> >> at:
> >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
> >>
> >> I don't expect any proposal to please everybody; there are
> >> unavoidable tradeoffs to increasing the maximum block size. I
> >> prioritize implementation simplicity -- it is hard to write
> >> consensus-critical code, so simpler is better.
> >>
> >>
> >>
> >>
> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
> >> <gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>> Status:
> >> Draft Type: Standards Track Created: 2015-06-22
> >>
> >> ==Abstract==
> >>
> >> This BIP proposes replacing the fixed one megabyte maximum block
> >> size with a maximum size that grows over time at a predictable
> >> rate.
> >>
> >> ==Motivation==
> >>
> >> Transaction volume on the Bitcoin network has been growing, and
> >> will soon reach the one-megabyte-every-ten-minutes limit imposed by
> >> the one megabyte maximum block size. Increasing the maximum size
> >> reduces the impact of that limit on Bitcoin adoption and growth.
> >>
> >> ==Specification==
> >>
> >> After deployment on the network (see the Deployment section for
> >> details), the maximum allowed size of a block on the main network
> >> shall be calculated based on the timestamp in the block header.
> >>
> >> The maximum size shall be 8,000,000 bytes at a timestamp of
> >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
> >> every 63,072,000 seconds (two years, ignoring leap years), until
> >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
> >> blocks in between doublings will increase linearly based on the
> >> block's timestamp. The maximum size of blocks after 2036-01-06
> >> 00:00:00 UTC shall be 8,192,000,000 bytes.
> >>
> >> Expressed in pseudo-code, using integer math:
> >>
> >> function max_block_size(block_timestamp):
> >>
> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
> >> 8000000 if block_timestamp >= time_start+time_double*10 return
> >> size_start * 2^10
> >>
> >> // Piecewise-linear-between-doublings growth: time_delta =
> >> block_timestamp - t_start doublings = time_delta / time_double
> >> remainder = time_delta % time_double interpolate = (size_start *
> >> 2^doublings * remainder) / time_double max_size = size_start *
> >> 2^doublings + interpolate
> >>
> >> return max_size
> >>
> >> ==Deployment==
> >>
> >> Deployment shall be controlled by hash-power supermajority vote
> >> (similar to the technique used in BIP34), but the earliest possible
> >> activation time is 2016-01-11 00:00:00 UTC.
> >>
> >> Activation is achieved when 750 of 1,000 consecutive blocks in the
> >> best chain have a version number with bits 3 and 14 set (0x20000004
> >> in hex). The activation time will be the timestamp of the 750'th
> >> block plus a two week (1,209,600 second) grace period to give any
> >> remaining miners or services time to upgrade to support larger
> >> blocks. If a supermajority is achieved more than two weeks before
> >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
> >> 00:00:00 UTC.
> >>
> >> Block version numbers are used only for activation; once activation
> >> is achieved, the maximum block size shall be as described in the
> >> specification section, regardless of the version number of the
> >> block.
> >>
> >>
> >> ==Rationale==
> >>
> >> The initial size of 8,000,000 bytes was chosen after testing the
> >> current reference implementation code with larger block sizes and
> >> receiving feedback from miners stuck behind bandwidth-constrained
> >> networks (in particular, Chinese miners behind the Great Firewall
> >> of China).
> >>
> >> The doubling interval was chosen based on long-term growth trends
> >> for CPU power, storage, and Internet bandwidth. The 20-year limit
> >> was chosen because exponential growth cannot continue forever.
> >>
> >> Calculations are based on timestamps and not blockchain height
> >> because a timestamp is part of every block's header. This allows
> >> implementations to know a block's maximum size after they have
> >> downloaded it's header, but before downloading any transactions.
> >>
> >> The deployment plan is taken from Jeff Garzik's proposed BIP100
> >> block size increase, and is designed to give miners, merchants,
> >> and full-node-running-end-users sufficient time to upgrade to
> >> software that supports bigger blocks. A 75% supermajority was
> >> chosen so that one large mining pool does not have effective veto
> >> power over a blocksize increase. The version number scheme is
> >> designed to be compatible with Pieter's Wuille's proposed "Version
> >> bits" BIP.
> >>
> >> TODO: summarize objections/arguments from
> >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
> >>
> >> TODO: describe other proposals and their advantages/disadvantages
> >> over this proposal.
> >>
> >>
> >> ==Compatibility==
> >>
> >> This is a hard-forking change to the Bitcoin protocol; anybody
> >> running code that fully validates blocks must upgrade before the
> >> activation time or they will risk rejecting a chain containing
> >> larger-than-one-megabyte blocks.
> >>
> >> Simplified Payment Verification software is not affected, unless
> >> it makes assumptions about the maximum depth of a transaction's
> >> merkle branch based on the minimum size of a transaction and the
> >> maximum block size.
> >>
> >> ==Implementation==
> >>
> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
> >>
> >>
> >>
> >> _______________________________________________ bitcoin-dev mailing
> >> list bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > - --
> > http://abis.io ~
> > "a protocol concept to enable decentralization
> > and expansion of a giving economy, and a new social good"
> > https://keybase.io/odinn
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
> > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
> > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
> > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
> > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
> > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
> > =ft62
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > 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
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 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
>
>
--047d7bacbbccb5a4f5051946c7ab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is no different than any other soft fork.=C2=A0 Prope=
r communication can coordinate soft forks easily.</div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Wed, Jun 24, 2015 at 12:23 PM, Ray=
stonn <span dir=3D"ltr"><<a href=3D"mailto:raystonn@hotmail.com" target=
=3D"_blank">raystonn@hotmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><p dir=3D"ltr">You really believe they would risk getting orp=
haned by skipping the longer chain, just to attempt to reduce average block=
size? No, that doesn't happen today. Laziness in leaving the default s=
ize is common. But that is not collusion, nor an attempt to manipulate the =
block sizes of other miners.<br>
</p><div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_quote">On 24 Jun 2015 10:05 am, Mark Friedenbach <<a=
href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.or=
g</a>> wrote:<br type=3D"attribution"><blockquote style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">They do so=
by not building on larger blocks</p>
<div>On Jun 23, 2015 9:31 PM, "Raystonn" <<a href=3D"mailto:ra=
ystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>> wrote:<b=
r><blockquote style=3D"margin:0 0 0 0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><p dir=3D"ltr">No, they can lower their own block sizes.=C2=A0 =
But they cannot currently lower the sizes of blocks mined by others.=C2=A0 =
That is not the same thing by any stretch of the imagination.</p>
<div>On 23 Jun 2015 8:50 pm, Jeff Garzik <<a href=3D"mailto:jgarzik@gmai=
l.com" target=3D"_blank">jgarzik@gmail.com</a>> wrote:<br><blockquote st=
yle=3D"margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr">Miners can collude today to lower the block size limit.<div><b=
r></div><div>In fact, this largely happens already out of laziness - miners=
often follow the "soft" default limit set by Bitcoin Core, to th=
e point where you can chart when miners upgrade to new software:=C2=A0<a hr=
ef=3D"http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-blo=
ck" target=3D"_blank">http://hashingit.com/analysis/39-the-myth-of-the-mega=
byte-bitcoin-block</a></div><div><br></div><div><br></div></div><div><br><d=
iv>On Tue, Jun 23, 2015 at 8:05 PM, William Madden <span dir=3D"ltr"><<a=
href=3D"mailto:will.madden@novauri.com" target=3D"_blank">will.madden@nova=
uri.com</a>></span> wrote:<br><blockquote style=3D"margin:0 0 0 0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">Here are refutations of the appr=
oach in BIP-100 here:<br>
<a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf=
" target=3D"_blank">http://gtf.org/garzik/bitcoin/BIP100-blocksizechangepro=
posal.pdf</a><br>
<br>
To recap BIP-100:<br>
<br>
1) Hard form to remove static 1MB block size limit<br>
2) Add new floating block size limit set to 1MB<br>
3) Historical 32MB message limit remains<br>
4) Hard form on testnet 9/1/2015<br>
5) Hard form on main 1/11/2016<br>
6) 1MB limit changed via one-way lock in upgrade with a 12,000 block<br>
threshold by 90% of blocks<br>
7) Limit increase or decrease may not exceed 2x in any one step<br>
8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase=
<br>
scriptSig, e.g. "/BV8000000/" to vote for 8M.<br>
9) Votes are evaluated by dropping bottom 20% and top 20%, and then the<br>
most common floor (minimum) is chosen.<br>
<br>
8MB limits doubling just under every 2 years makes a static value grow<br>
in a predictable manner.<br>
<br>
BIP-100 makes a static value grow (or more importantly potentially<br>
shrink) in an unpredictable manner based on voting mechanics that are<br>
untested in this capacity in the bitcoin network.=C2=A0 Introducing a highl=
y<br>
variable and untested dynamic into an already complex system is<br>
unnecessarily risky.<br>
<br>
For example, the largely arbitrary voting rules listed in 9 above can be<br=
>
gamed.=C2=A0 If I control pools or have affiliates involved in pools that<b=
r>
mine slightly more than 20% of blocks, I could wait until block sizes<br>
are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks =
and<br>
"/BV5000001/" for the remaining 10%.=C2=A0 If others don't co=
nsistently vote<br>
for the same "/BV#/" value, vote too consistently and have their =
value<br>
thrown out as the top 20%, I could win the resize to half capacity<br>
"/BV5000001/" because it was the lowest repeated value not in the=
bottom<br>
20%.<br>
<br>
I could use this to force an exodus to my sidechain/alt coin, or to<br>
choke out the bitcoin network.=C2=A0 A first improvement would be to only l=
et<br>
BIP-100 raise the cap and not lower it, but if I can think of a<br>
vulnerability off the top of my head, there will be others on the other<br>
side of the equation that have not been thought of.=C2=A0 Why bother<br>
introducing a rube goldberg machine like voting when a simple 8mb cap<br>
with predictable growth gets the job done, potentially permanently?<br>
<div><div><br>
<br>
On 6/23/2015 9:43 PM, odinn wrote:<br>
> -----BEGIN PGP SIGNED MESSAGE-----<br>
> Hash: SHA1<br>
><br>
> 1) Hard fork not (necessarily) needed<br>
> 2) See Garzik's BIP 100, better (this is not meant to say "su=
perior to<br>
> your stuff," but rather simply to say, "Better you should wo=
rk with<br>
> Garzik to implement BIP-100, that would be good")<br>
> 3) See points 1 and 2 above<br>
> 4) If still reading... changes should be (as you seem to have been<br>
> trying to lean towards)... lean towards gradual change; hence, changes=
<br>
> that would flow from this BIP would be better off oriented in a<br>
> process that dies not require the "way you have done it."<br=
>
><br>
> You did address that, to be fair - in your TODO, this link:<br>
> <a href=3D"http://gavinandresen.ninja/time-to-roll-out-bigger-blocks" =
target=3D"_blank">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks=
</a><br>
><br>
> contained the following link:<br>
><br>
> <a href=3D"http://gavinandresen.ninja/bigger-blocks-another-way" targe=
t=3D"_blank">http://gavinandresen.ninja/bigger-blocks-another-way</a><br>
><br>
> However, in reading that, I didn't see any meaningful statements t=
hat<br>
> would refute the approach in Garzik's BIP-100.<br>
><br>
> Maybe a better way to say this is,<br>
><br>
> Work with Jeff Garzik (which I am sure you are already having such<br>
> discussions in private) as well as the list discussions,<br>
> Move forward on BIP-100 with Garzik and other developers (not such a<b=
r>
> bad plan really) and don't get caught up in XT.=C2=A0 (If you feel=
you can<br>
> develop XT further, that is your thing but it would perhaps make you<b=
r>
> lose focus, work together with other developers.)<br>
><br>
> Relax into the process.=C2=A0 Things will be ok.<br>
><br>
> Respectfully,<br>
><br>
> - -O<br>
><br>
> On 06/22/2015 11:18 AM, Gavin Andresen wrote:<br>
>> I promised to write a BIP after I'd implemented<br>
>> increase-the-maximum-block-size code, so here it is. It also lives=
<br>
>> at:<br>
>> <a href=3D"https://github.com/gavinandresen/bips/blob/blocksize/bi=
p-8MB.mediawiki" target=3D"_blank">https://github.com/gavinandresen/bips/bl=
ob/blocksize/bip-8MB.mediawiki</a><br>
>><br>
>>=C2=A0 I don't expect any proposal to please everybody; there a=
re<br>
>> unavoidable tradeoffs to increasing the maximum block size. I<br>
>> prioritize implementation simplicity -- it is hard to write<br>
>> consensus-critical code, so simpler is better.<br>
>><br>
>><br>
>><br>
>><br>
>> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen<=
br>
>> <<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">g=
avinandresen@gmail.com</a> <mailto:<a href=3D"mailto:gavinandresen@gmail=
.com" target=3D"_blank">gavinandresen@gmail.com</a>>> Status:<br>
>> Draft Type: Standards Track Created: 2015-06-22<br>
>><br>
>> =3D=3DAbstract=3D=3D<br>
>><br>
>> This BIP proposes replacing the fixed one megabyte maximum block<b=
r>
>> size with a maximum size that grows over time at a predictable<br>
>> rate.<br>
>><br>
>> =3D=3DMotivation=3D=3D<br>
>><br>
>> Transaction volume on the Bitcoin network has been growing, and<br=
>
>> will soon reach the one-megabyte-every-ten-minutes limit imposed b=
y<br>
>> the one megabyte maximum block size. Increasing the maximum size<b=
r>
>> reduces the impact of that limit on Bitcoin adoption and growth.<b=
r>
>><br>
>> =3D=3DSpecification=3D=3D<br>
>><br>
>> After deployment on the network (see the Deployment section for<br=
>
>> details), the maximum allowed size of a block on the main network<=
br>
>> shall be calculated based on the timestamp in the block header.<br=
>
>><br>
>> The maximum size shall be 8,000,000 bytes at a timestamp of<br>
>> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double<b=
r>
>> every 63,072,000 seconds (two years, ignoring leap years), until<b=
r>
>> 2036-01-06 00:00:00 UTC (timestamp <a href=3D"tel:2083190400" valu=
e=3D"+12083190400" target=3D"_blank">2083190400</a>). The maximum size of<b=
r>
>> blocks in between doublings will increase linearly based on the<br=
>
>> block's timestamp. The maximum size of blocks after 2036-01-06=
<br>
>> 00:00:00 UTC shall be 8,192,000,000 bytes.<br>
>><br>
>> Expressed in pseudo-code, using integer math:<br>
>><br>
>> function max_block_size(block_timestamp):<br>
>><br>
>> time_start =3D 1452470400 time_double =3D 60*60*24*365*2 size_star=
t =3D<br>
>> 8000000 if block_timestamp >=3D time_start+time_double*10 retur=
n<br>
>> size_start * 2^10<br>
>><br>
>> // Piecewise-linear-between-doublings growth: time_delta =3D<br>
>> block_timestamp - t_start doublings =3D time_delta / time_double<b=
r>
>> remainder =3D time_delta % time_double interpolate =3D (size_start=
*<br>
>> 2^doublings * remainder) / time_double max_size =3D size_start *<b=
r>
>> 2^doublings + interpolate<br>
>><br>
>> return max_size<br>
>><br>
>> =3D=3DDeployment=3D=3D<br>
>><br>
>> Deployment shall be controlled by hash-power supermajority vote<br=
>
>> (similar to the technique used in BIP34), but the earliest possibl=
e<br>
>> activation time is 2016-01-11 00:00:00 UTC.<br>
>><br>
>> Activation is achieved when 750 of 1,000 consecutive blocks in the=
<br>
>> best chain have a version number with bits 3 and 14 set (0x2000000=
4<br>
>> in hex). The activation time will be the timestamp of the 750'=
th<br>
>> block plus a two week (1,209,600 second) grace period to give any<=
br>
>> remaining miners or services time to upgrade to support larger<br>
>> blocks. If a supermajority is achieved more than two weeks before<=
br>
>> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11<br=
>
>> 00:00:00 UTC.<br>
>><br>
>> Block version numbers are used only for activation; once activatio=
n<br>
>> is achieved, the maximum block size shall be as described in the<b=
r>
>> specification section, regardless of the version number of the<br>
>> block.<br>
>><br>
>><br>
>> =3D=3DRationale=3D=3D<br>
>><br>
>> The initial size of 8,000,000 bytes was chosen after testing the<b=
r>
>> current reference implementation code with larger block sizes and<=
br>
>> receiving feedback from miners stuck behind bandwidth-constrained<=
br>
>> networks (in particular, Chinese miners behind the Great Firewall<=
br>
>> of China).<br>
>><br>
>> The doubling interval was chosen based on long-term growth trends<=
br>
>> for CPU power, storage, and Internet bandwidth. The 20-year limit<=
br>
>> was chosen because exponential growth cannot continue forever.<br>
>><br>
>> Calculations are based on timestamps and not blockchain height<br>
>> because a timestamp is part of every block's header. This allo=
ws<br>
>> implementations to know a block's maximum size after they have=
<br>
>> downloaded it's header, but before downloading any transaction=
s.<br>
>><br>
>> The deployment plan is taken from Jeff Garzik's proposed BIP10=
0<br>
>> block size increase, and is designed to give miners, merchants,<br=
>
>> and full-node-running-end-users sufficient time to upgrade to<br>
>> software that supports bigger blocks. A 75% supermajority was<br>
>> chosen so that one large mining pool does not have effective veto<=
br>
>> power over a blocksize increase. The version number scheme is<br>
>> designed to be compatible with Pieter's Wuille's proposed =
"Version<br>
>> bits" BIP.<br>
>><br>
>> TODO: summarize objections/arguments from<br>
>> <a href=3D"http://gavinandresen.ninja/time-to-roll-out-bigger-bloc=
ks" target=3D"_blank">http://gavinandresen.ninja/time-to-roll-out-bigger-bl=
ocks</a>.<br>
>><br>
>> TODO: describe other proposals and their advantages/disadvantages<=
br>
>> over this proposal.<br>
>><br>
>><br>
>> =3D=3DCompatibility=3D=3D<br>
>><br>
>> This is a hard-forking change to the Bitcoin protocol; anybody<br>
>> running code that fully validates blocks must upgrade before the<b=
r>
>> activation time or they will risk rejecting a chain containing<br>
>> larger-than-one-megabyte blocks.<br>
>><br>
>> Simplified Payment Verification software is not affected, unless<b=
r>
>> it makes assumptions about the maximum depth of a transaction'=
s<br>
>> merkle branch based on the minimum size of a transaction and the<b=
r>
>> maximum block size.<br>
>><br>
>> =3D=3DImplementation=3D=3D<br>
>><br>
>> <a href=3D"https://github.com/gavinandresen/bitcoinxt/tree/blocksi=
ze_fork" target=3D"_blank">https://github.com/gavinandresen/bitcoinxt/tree/=
blocksize_fork</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________ bitcoin-dev mailin=
g<br>
>> list <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listin=
fo/bitcoin-dev</a><br>
>><br>
><br>
> - --<br>
> <a href=3D"http://abis.io" target=3D"_blank">http://abis.io</a> ~<br>
> "a protocol concept to enable decentralization<br>
> and expansion of a giving economy, and a new social good"<br>
> <a href=3D"https://keybase.io/odinn" target=3D"_blank">https://keybase=
.io/odinn</a><br>
> -----BEGIN PGP SIGNATURE-----<br>
> Version: GnuPG v1<br>
><br>
> iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175<br>
> Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+<br>
> K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw<br>
> OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN<br>
> fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s<br>
> CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=3D<br>
> =3Dft62<br>
> -----END PGP SIGNATURE-----<br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/b=
itcoin-dev</a><br>
><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev</a><br>
<br></blockquote></div>
</blockquote></div></div></div><br>________________________________________=
_______<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--047d7bacbbccb5a4f5051946c7ab--
|