diff options
author | Allen Piscitello <allen.piscitello@gmail.com> | 2015-06-24 12:24:32 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-24 17:24:34 +0000 |
commit | 6f71af879b099a9cc47c0bcea72c2a290c50301a (patch) | |
tree | a92eab04e44e3e499d5c3f96bba5f827684a3e21 | |
parent | b2f7b333dda225f8d8941a01c4915666a33d2ac7 (diff) | |
download | pi-bitcoindev-6f71af879b099a9cc47c0bcea72c2a290c50301a.tar.gz pi-bitcoindev-6f71af879b099a9cc47c0bcea72c2a290c50301a.zip |
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
-rw-r--r-- | 7c/2e82f589e5a482a68184e254b6b4d1c3588d35 | 755 |
1 files changed, 755 insertions, 0 deletions
diff --git a/7c/2e82f589e5a482a68184e254b6b4d1c3588d35 b/7c/2e82f589e5a482a68184e254b6b4d1c3588d35 new file mode 100644 index 000000000..ef1f25e7c --- /dev/null +++ b/7c/2e82f589e5a482a68184e254b6b4d1c3588d35 @@ -0,0 +1,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-- + |