Return-Path: <mark@friedenbach.org> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B57ECBCD for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 24 Jun 2015 17:05:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F0FF31BA for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 24 Jun 2015 17:05:42 +0000 (UTC) Received: by iebrt9 with SMTP id rt9so37530034ieb.2 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 24 Jun 2015 10:05:42 -0700 (PDT) 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=9uj+sODXSlzw8Xyksfd0VRf5bIm7w616DkuuvGCOhg0=; b=UuAdoaeebRJTQyhctva7cEW2Bpi/7+BNI1/tVUcBMCPDJnFiZ0g3EJV3vdEVXwfO6u z4cHTFUomkRM1h2K6o2l667rCm0fnZ0ptUBpqNfX1wPDtXzoZ3xc8RtNTLVP3Z6m5NrP I5NkXLaLjmtG2Iu0Hzw/Ic/+IxFdR2dFtOOqpSnwexVDre3X0uDyvPkz+Ja1MJf/xSPg k5wTx2N9MK0S1o7r4pjZ7gDc+1WVCWBEei5dpQweHkkyPPeKULszf1uIDyyLiqZ8hjvS ttU+JfugRcuC7kFNKD7bu+YN+Y0ffeu72idss2zuwCCxPFIG1HeU5FJEsQvns+HXGcHn 4FsA== X-Gm-Message-State: ALoCoQnwo8fgmMHaQ7TJOSid4z6RTVs5TGKsx+3CibwZo09vNoOgrolju3qWNmWbJnwGoJ1Qnqv7 MIME-Version: 1.0 X-Received: by 10.107.135.215 with SMTP id r84mr28582504ioi.13.1435165542393; Wed, 24 Jun 2015 10:05:42 -0700 (PDT) Received: by 10.107.149.20 with HTTP; Wed, 24 Jun 2015 10:05:42 -0700 (PDT) X-Originating-IP: [172.56.16.75] Received: by 10.107.149.20 with HTTP; Wed, 24 Jun 2015 10:05:42 -0700 (PDT) In-Reply-To: <COL402-EAS813C9D07F7367E88D7219CDAF0@phx.gbl> References: <COL402-EAS813C9D07F7367E88D7219CDAF0@phx.gbl> Date: Wed, 24 Jun 2015 10:05:42 -0700 Message-ID: <CAOG=w-uf3K+vW_zHXUm1utK7tR7osm_1hLMxw8gqkwm0Hn7d_A@mail.gmail.com> From: Mark Friedenbach <mark@friedenbach.org> To: Raystonn <raystonn@hotmail.com> Content-Type: multipart/alternative; boundary=001a113ec8885945f4051946843f X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@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:05:45 -0000 --001a113ec8885945f4051946843f Content-Type: text/plain; charset=UTF-8 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 > > --001a113ec8885945f4051946843f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">They do so by not building on larger blocks</p> <div class=3D"gmail_quote">On Jun 23, 2015 9:31 PM, "Raystonn" &l= t;<a href=3D"mailto:raystonn@hotmail.com">raystonn@hotmail.com</a>> wrot= e:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">No= , they can lower their own block sizes.=C2=A0 But they cannot currently low= er the sizes of blocks mined by others.=C2=A0 That is not the same thing by= any stretch of the imagination.</p> <div class=3D"gmail_quote">On 23 Jun 2015 8:50 pm, Jeff Garzik <<a href= =3D"mailto:jgarzik@gmail.com" target=3D"_blank">jgarzik@gmail.com</a>> w= rote:<br type=3D"attribution"><blockquote style=3D"margin: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><br></div><div>In fact, this large= ly happens already out of laziness - miners often follow the "soft&quo= t; default limit set by Bitcoin Core, to the point where you can chart when= miners upgrade to new software:=C2=A0<a href=3D"http://hashingit.com/analy= sis/39-the-myth-of-the-megabyte-bitcoin-block" target=3D"_blank">http://has= hingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block</a></div><div= ><br></div><div><br></div></div><div><br><div>On Tue, Jun 23, 2015 at 8:05 = PM, William Madden <span dir=3D"ltr"><<a href=3D"mailto:will.madden@nova= uri.com" target=3D"_blank">will.madden@novauri.com</a>></span> wrote:<br= ><blockquote style=3D"margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding= -left:1ex">Here are refutations of the approach 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">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> --001a113ec8885945f4051946843f--