summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAllen Piscitello <allen.piscitello@gmail.com>2015-06-24 12:24:32 -0500
committerbitcoindev <bitcoindev@gnusha.org>2015-06-24 17:24:34 +0000
commit6f71af879b099a9cc47c0bcea72c2a290c50301a (patch)
treea92eab04e44e3e499d5c3f96bba5f827684a3e21
parentb2f7b333dda225f8d8941a01c4915666a33d2ac7 (diff)
downloadpi-bitcoindev-6f71af879b099a9cc47c0bcea72c2a290c50301a.tar.gz
pi-bitcoindev-6f71af879b099a9cc47c0bcea72c2a290c50301a.zip
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
-rw-r--r--7c/2e82f589e5a482a68184e254b6b4d1c3588d35755
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">&lt;<a href=3D"mailto:raystonn@hotmail.com" target=
+=3D"_blank">raystonn@hotmail.com</a>&gt;</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&#39;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 &lt;<a=
+ href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.or=
+g</a>&gt; 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, &quot;Raystonn&quot; &lt;<a href=3D"mailto:ra=
+ystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>&gt; 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 &lt;<a href=3D"mailto:jgarzik@gmai=
+l.com" target=3D"_blank">jgarzik@gmail.com</a>&gt; 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 &quot;soft&quot; 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">&lt;<a=
+ href=3D"mailto:will.madden@novauri.com" target=3D"_blank">will.madden@nova=
+uri.com</a>&gt;</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 &#39;BV&#39;+BlockSizeRequestValue into coinbase=
+<br>
+scriptSig, e.g. &quot;/BV8000000/&quot; 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 &quot;/BV5000000/&quot; for 20% of blocks =
+and<br>
+&quot;/BV5000001/&quot; for the remaining 10%.=C2=A0 If others don&#39;t co=
+nsistently vote<br>
+for the same &quot;/BV#/&quot; value, vote too consistently and have their =
+value<br>
+thrown out as the top 20%, I could win the resize to half capacity<br>
+&quot;/BV5000001/&quot; 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>
+&gt; -----BEGIN PGP SIGNED MESSAGE-----<br>
+&gt; Hash: SHA1<br>
+&gt;<br>
+&gt; 1) Hard fork not (necessarily) needed<br>
+&gt; 2) See Garzik&#39;s BIP 100, better (this is not meant to say &quot;su=
+perior to<br>
+&gt; your stuff,&quot; but rather simply to say, &quot;Better you should wo=
+rk with<br>
+&gt; Garzik to implement BIP-100, that would be good&quot;)<br>
+&gt; 3) See points 1 and 2 above<br>
+&gt; 4) If still reading... changes should be (as you seem to have been<br>
+&gt; trying to lean towards)... lean towards gradual change; hence, changes=
+<br>
+&gt; that would flow from this BIP would be better off oriented in a<br>
+&gt; process that dies not require the &quot;way you have done it.&quot;<br=
+>
+&gt;<br>
+&gt; You did address that, to be fair - in your TODO, this link:<br>
+&gt; <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>
+&gt;<br>
+&gt; contained the following link:<br>
+&gt;<br>
+&gt; <a href=3D"http://gavinandresen.ninja/bigger-blocks-another-way" targe=
+t=3D"_blank">http://gavinandresen.ninja/bigger-blocks-another-way</a><br>
+&gt;<br>
+&gt; However, in reading that, I didn&#39;t see any meaningful statements t=
+hat<br>
+&gt; would refute the approach in Garzik&#39;s BIP-100.<br>
+&gt;<br>
+&gt; Maybe a better way to say this is,<br>
+&gt;<br>
+&gt; Work with Jeff Garzik (which I am sure you are already having such<br>
+&gt; discussions in private) as well as the list discussions,<br>
+&gt; Move forward on BIP-100 with Garzik and other developers (not such a<b=
+r>
+&gt; bad plan really) and don&#39;t get caught up in XT.=C2=A0 (If you feel=
+ you can<br>
+&gt; develop XT further, that is your thing but it would perhaps make you<b=
+r>
+&gt; lose focus, work together with other developers.)<br>
+&gt;<br>
+&gt; Relax into the process.=C2=A0 Things will be ok.<br>
+&gt;<br>
+&gt; Respectfully,<br>
+&gt;<br>
+&gt; - -O<br>
+&gt;<br>
+&gt; On 06/22/2015 11:18 AM, Gavin Andresen wrote:<br>
+&gt;&gt; I promised to write a BIP after I&#39;d implemented<br>
+&gt;&gt; increase-the-maximum-block-size code, so here it is. It also lives=
+<br>
+&gt;&gt; at:<br>
+&gt;&gt; <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>
+&gt;&gt;<br>
+&gt;&gt;=C2=A0 I don&#39;t expect any proposal to please everybody; there a=
+re<br>
+&gt;&gt; unavoidable tradeoffs to increasing the maximum block size. I<br>
+&gt;&gt; prioritize implementation simplicity -- it is hard to write<br>
+&gt;&gt; consensus-critical code, so simpler is better.<br>
+&gt;&gt;<br>
+&gt;&gt;<br>
+&gt;&gt;<br>
+&gt;&gt;<br>
+&gt;&gt; BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen<=
+br>
+&gt;&gt; &lt;<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">g=
+avinandresen@gmail.com</a> &lt;mailto:<a href=3D"mailto:gavinandresen@gmail=
+.com" target=3D"_blank">gavinandresen@gmail.com</a>&gt;&gt; Status:<br>
+&gt;&gt; Draft Type: Standards Track Created: 2015-06-22<br>
+&gt;&gt;<br>
+&gt;&gt; =3D=3DAbstract=3D=3D<br>
+&gt;&gt;<br>
+&gt;&gt; This BIP proposes replacing the fixed one megabyte maximum block<b=
+r>
+&gt;&gt; size with a maximum size that grows over time at a predictable<br>
+&gt;&gt; rate.<br>
+&gt;&gt;<br>
+&gt;&gt; =3D=3DMotivation=3D=3D<br>
+&gt;&gt;<br>
+&gt;&gt; Transaction volume on the Bitcoin network has been growing, and<br=
+>
+&gt;&gt; will soon reach the one-megabyte-every-ten-minutes limit imposed b=
+y<br>
+&gt;&gt; the one megabyte maximum block size. Increasing the maximum size<b=
+r>
+&gt;&gt; reduces the impact of that limit on Bitcoin adoption and growth.<b=
+r>
+&gt;&gt;<br>
+&gt;&gt; =3D=3DSpecification=3D=3D<br>
+&gt;&gt;<br>
+&gt;&gt; After deployment on the network (see the Deployment section for<br=
+>
+&gt;&gt; details), the maximum allowed size of a block on the main network<=
+br>
+&gt;&gt; shall be calculated based on the timestamp in the block header.<br=
+>
+&gt;&gt;<br>
+&gt;&gt; The maximum size shall be 8,000,000 bytes at a timestamp of<br>
+&gt;&gt; 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double<b=
+r>
+&gt;&gt; every 63,072,000 seconds (two years, ignoring leap years), until<b=
+r>
+&gt;&gt; 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>
+&gt;&gt; blocks in between doublings will increase linearly based on the<br=
+>
+&gt;&gt; block&#39;s timestamp. The maximum size of blocks after 2036-01-06=
+<br>
+&gt;&gt; 00:00:00 UTC shall be 8,192,000,000 bytes.<br>
+&gt;&gt;<br>
+&gt;&gt; Expressed in pseudo-code, using integer math:<br>
+&gt;&gt;<br>
+&gt;&gt; function max_block_size(block_timestamp):<br>
+&gt;&gt;<br>
+&gt;&gt; time_start =3D 1452470400 time_double =3D 60*60*24*365*2 size_star=
+t =3D<br>
+&gt;&gt; 8000000 if block_timestamp &gt;=3D time_start+time_double*10 retur=
+n<br>
+&gt;&gt; size_start * 2^10<br>
+&gt;&gt;<br>
+&gt;&gt; // Piecewise-linear-between-doublings growth: time_delta =3D<br>
+&gt;&gt; block_timestamp - t_start doublings =3D time_delta / time_double<b=
+r>
+&gt;&gt; remainder =3D time_delta % time_double interpolate =3D (size_start=
+ *<br>
+&gt;&gt; 2^doublings * remainder) / time_double max_size =3D size_start *<b=
+r>
+&gt;&gt; 2^doublings + interpolate<br>
+&gt;&gt;<br>
+&gt;&gt; return max_size<br>
+&gt;&gt;<br>
+&gt;&gt; =3D=3DDeployment=3D=3D<br>
+&gt;&gt;<br>
+&gt;&gt; Deployment shall be controlled by hash-power supermajority vote<br=
+>
+&gt;&gt; (similar to the technique used in BIP34), but the earliest possibl=
+e<br>
+&gt;&gt; activation time is 2016-01-11 00:00:00 UTC.<br>
+&gt;&gt;<br>
+&gt;&gt; Activation is achieved when 750 of 1,000 consecutive blocks in the=
+<br>
+&gt;&gt; best chain have a version number with bits 3 and 14 set (0x2000000=
+4<br>
+&gt;&gt; in hex). The activation time will be the timestamp of the 750&#39;=
+th<br>
+&gt;&gt; block plus a two week (1,209,600 second) grace period to give any<=
+br>
+&gt;&gt; remaining miners or services time to upgrade to support larger<br>
+&gt;&gt; blocks. If a supermajority is achieved more than two weeks before<=
+br>
+&gt;&gt; 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11<br=
+>
+&gt;&gt; 00:00:00 UTC.<br>
+&gt;&gt;<br>
+&gt;&gt; Block version numbers are used only for activation; once activatio=
+n<br>
+&gt;&gt; is achieved, the maximum block size shall be as described in the<b=
+r>
+&gt;&gt; specification section, regardless of the version number of the<br>
+&gt;&gt; block.<br>
+&gt;&gt;<br>
+&gt;&gt;<br>
+&gt;&gt; =3D=3DRationale=3D=3D<br>
+&gt;&gt;<br>
+&gt;&gt; The initial size of 8,000,000 bytes was chosen after testing the<b=
+r>
+&gt;&gt; current reference implementation code with larger block sizes and<=
+br>
+&gt;&gt; receiving feedback from miners stuck behind bandwidth-constrained<=
+br>
+&gt;&gt; networks (in particular, Chinese miners behind the Great Firewall<=
+br>
+&gt;&gt; of China).<br>
+&gt;&gt;<br>
+&gt;&gt; The doubling interval was chosen based on long-term growth trends<=
+br>
+&gt;&gt; for CPU power, storage, and Internet bandwidth. The 20-year limit<=
+br>
+&gt;&gt; was chosen because exponential growth cannot continue forever.<br>
+&gt;&gt;<br>
+&gt;&gt; Calculations are based on timestamps and not blockchain height<br>
+&gt;&gt; because a timestamp is part of every block&#39;s header. This allo=
+ws<br>
+&gt;&gt; implementations to know a block&#39;s maximum size after they have=
+<br>
+&gt;&gt; downloaded it&#39;s header, but before downloading any transaction=
+s.<br>
+&gt;&gt;<br>
+&gt;&gt; The deployment plan is taken from Jeff Garzik&#39;s proposed BIP10=
+0<br>
+&gt;&gt; block size increase, and is designed to give miners, merchants,<br=
+>
+&gt;&gt; and full-node-running-end-users sufficient time to upgrade to<br>
+&gt;&gt; software that supports bigger blocks. A 75% supermajority was<br>
+&gt;&gt; chosen so that one large mining pool does not have effective veto<=
+br>
+&gt;&gt; power over a blocksize increase. The version number scheme is<br>
+&gt;&gt; designed to be compatible with Pieter&#39;s Wuille&#39;s proposed =
+&quot;Version<br>
+&gt;&gt; bits&quot; BIP.<br>
+&gt;&gt;<br>
+&gt;&gt; TODO: summarize objections/arguments from<br>
+&gt;&gt; <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>
+&gt;&gt;<br>
+&gt;&gt; TODO: describe other proposals and their advantages/disadvantages<=
+br>
+&gt;&gt; over this proposal.<br>
+&gt;&gt;<br>
+&gt;&gt;<br>
+&gt;&gt; =3D=3DCompatibility=3D=3D<br>
+&gt;&gt;<br>
+&gt;&gt; This is a hard-forking change to the Bitcoin protocol; anybody<br>
+&gt;&gt; running code that fully validates blocks must upgrade before the<b=
+r>
+&gt;&gt; activation time or they will risk rejecting a chain containing<br>
+&gt;&gt; larger-than-one-megabyte blocks.<br>
+&gt;&gt;<br>
+&gt;&gt; Simplified Payment Verification software is not affected, unless<b=
+r>
+&gt;&gt; it makes assumptions about the maximum depth of a transaction&#39;=
+s<br>
+&gt;&gt; merkle branch based on the minimum size of a transaction and the<b=
+r>
+&gt;&gt; maximum block size.<br>
+&gt;&gt;<br>
+&gt;&gt; =3D=3DImplementation=3D=3D<br>
+&gt;&gt;<br>
+&gt;&gt; <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>
+&gt;&gt;<br>
+&gt;&gt;<br>
+&gt;&gt;<br>
+&gt;&gt; _______________________________________________ bitcoin-dev mailin=
+g<br>
+&gt;&gt; list <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
+et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
+&gt;&gt; <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>
+&gt;&gt;<br>
+&gt;<br>
+&gt; - --<br>
+&gt; <a href=3D"http://abis.io" target=3D"_blank">http://abis.io</a> ~<br>
+&gt; &quot;a protocol concept to enable decentralization<br>
+&gt; and expansion of a giving economy, and a new social good&quot;<br>
+&gt; <a href=3D"https://keybase.io/odinn" target=3D"_blank">https://keybase=
+.io/odinn</a><br>
+&gt; -----BEGIN PGP SIGNATURE-----<br>
+&gt; Version: GnuPG v1<br>
+&gt;<br>
+&gt; iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175<br>
+&gt; Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+<br>
+&gt; K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw<br>
+&gt; OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN<br>
+&gt; fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s<br>
+&gt; CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=3D<br>
+&gt; =3Dft62<br>
+&gt; -----END PGP SIGNATURE-----<br>
+&gt; _______________________________________________<br>
+&gt; bitcoin-dev mailing list<br>
+&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
+ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
+&gt; <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>
+&gt;<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--
+