MIME-Version: 1.0
In-Reply-To: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 22 Jun 2015 14:52:32 -0700
Message-ID: <CAOG=w-tYr1pAXUq-2Zf1gEgYS+UEvFOoyBvQUTMBoHuu30s0Pg@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a1135ffb8a718330519224b02
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Precedence: list

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

Can you please add a discussion of the tradeoffs of decentralization vs
block size?

On Mon, Jun 22, 2015 at 11:18 AM, Gavin Andresen <gavinandresen@gmail.com>
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>
>   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
>
>

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

<div dir=3D"ltr">Can you please add a discussion of the tradeoffs of decent=
ralization vs block size?<br></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Mon, Jun 22, 2015 at 11:18 AM, Gavin Andresen <span di=
r=3D"ltr">&lt;<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">=
gavinandresen@gmail.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"><div dir=3D"ltr"><div>I promised to write a BIP after I&#39;d implemen=
ted increase-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" target=3D"_blank">https://github.com/gavinandresen/bips/blob=
/blocksize/bip-8MB.mediawiki</a></div><div><br></div><div>I don&#39;t expec=
t any proposal to please everybody; there are unavoidable tradeoffs to incr=
easing the maximum block size. I prioritize implementation simplicity -- it=
 is hard to write consensus-critical code, so simpler is better.=C2=A0</div=
><div><br></div><div><br></div><div><br></div><div><br></div><div><div clas=
s=3D"gmail_extra"><div 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:gavina=
ndresen@gmail.com" target=3D"_blank">gavinandresen@gmail.com</a>&gt;</div><=
div class=3D"gmail_extra">=C2=A0 Status: Draft</div><div class=3D"gmail_ext=
ra">=C2=A0 Type: Standards Track</div><div class=3D"gmail_extra">=C2=A0 Cre=
ated: 2015-06-22</div><div class=3D"gmail_extra"><br></div><div class=3D"gm=
ail_extra">=3D=3DAbstract=3D=3D</div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">This BIP proposes replacing the fixed one megabyt=
e maximum block size with a maximum size that grows over time at a predicta=
ble rate.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">=3D=3DMotivation=3D=3D</div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra">Transaction volume on the Bitcoin network has been gro=
wing, 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.</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 header.</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:00 UTC (timestamp 1452470400), and=
 shall double every 63,072,000 seconds (two years, ignoring leap years), un=
til 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blo=
cks in between doublings will increase linearly based on the block&#39;s ti=
mestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be =
8,192,000,000 bytes.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">Expressed in pseudo-code, using integer math:</div><div cl=
ass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 =C2=A0 func=
tion 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><div 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 r=
eturn size_start * 2^10</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 // Piecewise-linear-between-d=
oublings 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_de=
lta % time_double</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 interpolate =3D (size_start * 2^doublings * remainder) / time_double</d=
iv><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></di=
v><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return max_size</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=3D=3DDe=
ployment=3D=3D</div><div class=3D"gmail_extra"><br></div><div class=3D"gmai=
l_extra">Deployment shall be controlled by hash-power supermajority vote (s=
imilar to the technique used in BIP34), but the earliest possible activatio=
n time is 2016-01-11 00:00:00 UTC.</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">Activation is achieved when 750 of 1,000 conse=
cutive blocks in the best chain have a version number with bits 3 and 14 se=
t (0x20000004 in hex). The activation time will be the timestamp of the 750=
&#39;th block plus a two week (1,209,600 second) grace period to give any r=
emaining 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 UT=
C, the activation time will be 2016-01-11 00: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 s=
ize shall be as described in the specification section, regardless of the v=
ersion 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 chosen after testing the current r=
eference implementation code with larger block sizes and receiving feedback=
 from miners stuck behind bandwidth-constrained networks (in particular, Ch=
inese miners behind the Great Firewall of China).</div><div class=3D"gmail_=
extra"><br></div><div class=3D"gmail_extra">The doubling interval was chose=
n based on long-term growth trends for CPU power, storage, and Internet ban=
dwidth. The 20-year limit was chosen because exponential growth cannot cont=
inue forever.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail=
_extra">Calculations are based on timestamps and not blockchain height beca=
use a timestamp is part of every block&#39;s header. This allows implementa=
tions to know a block&#39;s maximum size after they have downloaded it&#39;=
s header, but before downloading any transactions.</div><div class=3D"gmail=
_extra"><br></div><div class=3D"gmail_extra">The deployment plan is taken f=
rom Jeff Garzik&#39;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 ov=
er a blocksize increase. The version number scheme is designed to be compat=
ible with Pieter&#39;s Wuille&#39;s proposed &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/t=
ime-to-roll-out-bigger-blocks" target=3D"_blank">http://gavinandresen.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 adv=
antages/disadvantages over this proposal.</div><div class=3D"gmail_extra"><=
br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
=3D=3DCompatibility=3D=3D</div><div class=3D"gmail_extra"><br></div><div cl=
ass=3D"gmail_extra">This is a hard-forking change to the Bitcoin protocol; =
anybody running code that fully validates blocks must upgrade before the ac=
tivation time or they will risk rejecting a chain containing larger-than-on=
e-megabyte blocks.</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">Simplified Payment Verification software is not affected, unle=
ss it makes assumptions about the maximum depth of a transaction&#39;s merk=
le branch based on the minimum size of a transaction and the maximum block =
size.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
=3D=3DImplementation=3D=3D</div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra"><a href=3D"https://github.com/gavinandresen/bitcoinxt/=
tree/blocksize_fork" target=3D"_blank">https://github.com/gavinandresen/bit=
coinxt/tree/blocksize_fork</a></div><div class=3D"gmail_extra"><br></div>
</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>

--001a1135ffb8a718330519224b02--