path: root/2a/0499ecdb4586f25a82ece5a144430b7e62663f

Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4B397AAC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 03:49:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com
	[209.85.212.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33C8D143
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 03:49:53 +0000 (UTC)
Received: by wiga1 with SMTP id a1so123333191wig.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 Jun 2015 20:49:51 -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=n5KNyrAk+CVvohPiE8Be+m98BNuO7TAvvjSKkn0+tBs=;
	b=VIFxjkkIeTZdWwGMRW6xKBq+KB+WJBDDfFXHcpIBWTvnyfK0ldiHx/UVYRf6ncCi1A
	g6LbEezk+mDC9qw1C6A/IYawlG1UgbPDbj1rOALldynpY/Foj6XkYeafTq8aHEnWyj8i
	KcqfyYYa+6a4Xq/0TnJzcOJr4sVyVVoq/yK06bY+87/ya1rjFV9gYcKDDNII8B2h8jCA
	s8Ov7OYOBdwA4+USzegVvssBML+iEjfv/ROmdiO2iXh7maSVO7oW+wCNdXNeE7+dSxmv
	PppD/ri1mSIn6lzQ/kyQTKYwfsAWuuFHWQDF7//jwLK/0HfjUSyfMp6/pRbuTZ4gAlwe
	gBbw==
MIME-Version: 1.0
X-Received: by 10.180.101.138 with SMTP id fg10mr751330wib.46.1435117791594;
	Tue, 23 Jun 2015 20:49:51 -0700 (PDT)
Received: by 10.28.176.2 with HTTP; Tue, 23 Jun 2015 20:49:51 -0700 (PDT)
In-Reply-To: <558A1E8E.30306@novauri.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
	<558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com>
Date: Tue, 23 Jun 2015 20:49:51 -0700
Message-ID: <CADm_WcZ52_fvNk_rWzu+Nw1CBz2o6t6cMkEfOm3BpdjH7iQKrw@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: William Madden <will.madden@novauri.com>
Content-Type: multipart/alternative; boundary=f46d0444e9a52dce3405193b662e
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 03:49:59 -0000

--f46d0444e9a52dce3405193b662e
Content-Type: text/plain; charset=UTF-8

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
>

--f46d0444e9a52dce3405193b662e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Miners can collude today to lower the block size limit.<di=
v><br></div><div>In fact, this largely happens already out of laziness - mi=
ners often follow the &quot;soft&quot; default limit set by Bitcoin Core, t=
o the point where you can chart when miners upgrade to new software:=C2=A0<=
a href=3D"http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin=
-block">http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-b=
lock</a></div><div><br></div><div><br></div></div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Tue, Jun 23, 2015 at 8:05 PM, William M=
adden <span dir=3D"ltr">&lt;<a href=3D"mailto:will.madden@novauri.com" targ=
et=3D"_blank">will.madden@novauri.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin: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=
" rel=3D"noreferrer" target=3D"_blank">http://gtf.org/garzik/bitcoin/BIP100=
-blocksizechangeproposal.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 class=3D"HOEnZb"><div class=3D"h5"><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" =
rel=3D"noreferrer" target=3D"_blank">http://gavinandresen.ninja/time-to-rol=
l-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" rel=
=3D"noreferrer" target=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" rel=3D"noreferrer" target=3D"_blank">https://github.com/ga=
vinandresen/bips/blob/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">gavinandresen@gmail=
.com</a> &lt;mailto:<a href=3D"mailto:gavinandresen@gmail.com">gavinandrese=
n@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 2083190400). The maximum size o=
f<br>
&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" rel=3D"noreferrer" target=3D"_blank">http://gavinandresen.ninja/time-to=
-roll-out-bigger-blocks</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" rel=3D"noreferrer" target=3D"_blank">https://github.com/gavinandre=
sen/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">bitc=
oin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt;<br>
&gt;<br>
&gt; - --<br>
&gt; <a href=3D"http://abis.io" rel=3D"noreferrer" 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" rel=3D"noreferrer" target=3D"_bla=
nk">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">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<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>
</div></div></blockquote></div><br></div>

--f46d0444e9a52dce3405193b662e--