path: root/a7/a06666667ffce10bbede6b81b1b9193e13035e

Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F3549273
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 18:18:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com
	[209.85.217.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6C8FC17C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 18:18:21 +0000 (UTC)
Received: by lbbpo10 with SMTP id po10so14390654lbb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 11:18:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=XkeCS9nSnZeGt92F+MwLlXpKZOFsaURRRhnn++TZTLg=;
	b=cDgrwG4t7Kc+gEmZjewBdih3IorCptARw2nDB6ndue3Esvrxx7Wbdd4eH6o0qP/gam
	Y5qY5boZaQtIX0Xf/OkF8VrKnsUD9CB2jwy+uPkt+MV2SVK5BB5puvfO27+aJjx4Jba6
	N7KqaPB1SuLomE7EC0ZUFVCbfWxVWAm4qq/KhdUqHkLOSY8OPumt1JkEQE490ZLmkRx/
	gdOxHinqtD3+AUj8ksZsSu6ZHr5Ew5Oe5MmSEiG8TkV8M8euJf5ONhVCovT5PRxlr9wB
	6WsVxp5iyTINHhUIBXW1GTJL5Urlslvb6XTkiWphCzXTnuX0XFsy980Xd3lwQpisUJy4
	/CJA==
MIME-Version: 1.0
X-Received: by 10.112.155.103 with SMTP id vv7mr25796506lbb.75.1434997099501; 
	Mon, 22 Jun 2015 11:18:19 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Mon, 22 Jun 2015 11:18:19 -0700 (PDT)
Date: Mon, 22 Jun 2015 14:18:19 -0400
Message-ID: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Johnathan Corgan <johnathan@corganlabs.com>
Content-Type: multipart/alternative; boundary=089e01160c0e5ea2e905191f4c6a
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: [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: Mon, 22 Jun 2015 18:18:23 -0000

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

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>
  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

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

<div dir=3D"ltr"><div>I promised to write a BIP after I&#39;d implemented i=
ncrease-the-maximum-block-size code, so here it is. It also lives at: =C2=
=A0 <a href=3D"https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB=
.mediawiki">https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.me=
diawiki</a></div><div><br></div><div>I don&#39;t expect any proposal to ple=
ase everybody; there are unavoidable tradeoffs to increasing the maximum bl=
ock size. I prioritize implementation simplicity -- it is hard to write con=
sensus-critical code, so simpler is better.=C2=A0</div><div><br></div><div>=
<br></div><div><br></div><div><br></div><div><div class=3D"gmail_extra"><di=
v class=3D"gmail_extra">=C2=A0 BIP: ??</div><div class=3D"gmail_extra">=C2=
=A0 Title: Increase Maximum Block Size</div><div class=3D"gmail_extra">=C2=
=A0 Author: Gavin Andresen &lt;<a href=3D"mailto:gavinandresen@gmail.com">g=
avinandresen@gmail.com</a>&gt;</div><div class=3D"gmail_extra">=C2=A0 Statu=
s: Draft</div><div class=3D"gmail_extra">=C2=A0 Type: Standards Track</div>=
<div class=3D"gmail_extra">=C2=A0 Created: 2015-06-22</div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">=3D=3DAbstract=3D=3D</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This BIP pro=
poses replacing the fixed one megabyte maximum block size with a maximum si=
ze that grows over time at a predictable rate.</div><div class=3D"gmail_ext=
ra"><br></div><div class=3D"gmail_extra">=3D=3DMotivation=3D=3D</div><div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Transaction volum=
e on the Bitcoin network has been growing, and will soon reach the one-mega=
byte-every-ten-minutes limit imposed by the one megabyte maximum block size=
. Increasing the maximum size reduces the impact of that limit on Bitcoin a=
doption and growth.</div><div class=3D"gmail_extra"><br></div><div class=3D=
"gmail_extra">=3D=3DSpecification=3D=3D</div><div class=3D"gmail_extra"><br=
></div><div class=3D"gmail_extra">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 heade=
r.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The=
 maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:0=
0 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (tw=
o years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 208=
3190400). The maximum size of blocks in between doublings will increase lin=
early based on the block&#39;s timestamp. The maximum size of blocks after =
2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.</div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">Expressed in pseudo-code, u=
sing integer math:</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">=C2=A0 =C2=A0 function max_block_size(block_timestamp):</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 time_start =3D 1452470400</div><div class=3D"gmail_extra"=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 time_double =3D 60*60*24*365*2</div><div class=
=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 size_start =3D 8000000</div><d=
iv class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 if block_timestamp &gt=
;=3D time_start+time_double*10</div><div class=3D"gmail_extra">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return size_start * 2^10</div><div class=3D=
"gmail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 // Piecewise-linear-between-doublings growth:</div><div class=3D"gmail_=
extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 time_delta =3D block_timestamp - t_start=
</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 doublings =3D =
time_delta / time_double</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 remainder =3D time_delta % time_double</div><div class=3D"gmail_=
extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 interpolate =3D (size_start * 2^doubling=
s * remainder) / time_double</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 max_size =3D size_start * 2^doublings + interpolate</div><div=
 class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 return max_size</div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">=3D=3DDeployment=3D=3D</div><div class=3D"gmail_ext=
ra"><br></div><div class=3D"gmail_extra">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.</div><di=
v class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Activation is =
achieved when 750 of 1,000 consecutive blocks in the best chain have a vers=
ion number with bits 3 and 14 set (0x20000004 in hex). The activation time =
will be the timestamp of the 750&#39;th block plus a two week (1,209,600 se=
cond) grace period to give any remaining miners or services time to upgrade=
 to support larger blocks. If a supermajority is achieved more than two wee=
ks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 0=
0:00:00 UTC.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra">Block version numbers are used only for activation; once activation =
is achieved, the maximum block size shall be as described in the specificat=
ion section, regardless of the version number of the block.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">=3D=3DRationale=3D=3D</div><div class=3D"gmail_extra"><br>=
</div><div class=3D"gmail_extra">The initial size of 8,000,000 bytes was ch=
osen after testing the current reference implementation code with larger bl=
ock sizes and receiving feedback from miners stuck behind bandwidth-constra=
ined networks (in particular, Chinese miners behind the Great Firewall of C=
hina).</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"=
>The doubling interval was chosen based on long-term growth trends for CPU =
power, storage, and Internet bandwidth. The 20-year limit was chosen becaus=
e exponential growth cannot continue forever.</div><div class=3D"gmail_extr=
a"><br></div><div class=3D"gmail_extra">Calculations are based on timestamp=
s and not blockchain height because a timestamp is part of every block&#39;=
s header. This allows implementations to know a block&#39;s maximum size af=
ter they have downloaded it&#39;s header, but before downloading any transa=
ctions.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra=
">The deployment plan is taken from Jeff Garzik&#39;s proposed BIP100 block=
 size increase, and is designed to give miners, merchants, and full-node-ru=
nning-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&#39;s Wuille&#39;s propose=
d &quot;Version bits&quot; BIP.</div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">TODO: summarize objections/arguments from <a href=
=3D"http://gavinandresen.ninja/time-to-roll-out-bigger-blocks">http://gavin=
andresen.ninja/time-to-roll-out-bigger-blocks</a>.</div><div class=3D"gmail=
_extra"><br></div><div class=3D"gmail_extra">TODO: describe other proposals=
 and their advantages/disadvantages over this proposal.</div><div class=3D"=
gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">=3D=3DCompatibility=3D=3D</div><div class=3D"gmail_extra"><br><=
/div><div class=3D"gmail_extra">This is a hard-forking change to the Bitcoi=
n protocol; anybody running code that fully validates blocks must upgrade b=
efore the activation time or they will risk rejecting a chain containing la=
rger-than-one-megabyte blocks.</div><div class=3D"gmail_extra"><br></div><d=
iv class=3D"gmail_extra">Simplified Payment Verification software is not af=
fected, unless it makes assumptions about the maximum depth of a transactio=
n&#39;s merkle branch based on the minimum size of a transaction and the ma=
ximum block size.</div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">=3D=3DImplementation=3D=3D</div><div class=3D"gmail_extra"><br>=
</div><div class=3D"gmail_extra"><a href=3D"https://github.com/gavinandrese=
n/bitcoinxt/tree/blocksize_fork">https://github.com/gavinandresen/bitcoinxt=
/tree/blocksize_fork</a></div><div class=3D"gmail_extra"><br></div>
</div></div></div>

--089e01160c0e5ea2e905191f4c6a--