path: root/59/bbac9ff3e11f2e1c7700513529b18bbf10e01c

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 14722AB2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 21:52:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com
	[209.85.213.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E04CF126
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 21:52:52 +0000 (UTC)
Received: by igbiq7 with SMTP id iq7so63001658igb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 14:52:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=fJJgZIE9LXIskzDpauejU2utB73GVJTCnsPYiJc7gxc=;
	b=GnlhAAjixiwcRqQ5AO8aB0MOFB2j/TML76y/B2DWcYMcg/Hhk6NYC5idwzn6tyIqac
	3tiF+NQMm9YaNa2D7zmvoPI4IfXKWfFM1uihZuF1ylUXaQ+IsvE5L5Sh9L4/1dydd/TS
	9AzSmV5nJeVk4EO/bC+ZPTSF7VSCmEWsSWtuMv72PANMAMNuRpcPrxmFSx/My+MecVKf
	QJwCTrwZEcThXs1sbq5CkgByjWQTx5BNbxaKE4XIhndUELBKXHQpy9+0tzNerOmwdDH3
	ngfMtK2HXFFkN/4TnRASjhz7CkBeGJj0oqmhXk22bd4396M1nvruUZe7J7+xCPMoVhqr
	uj9g==
X-Gm-Message-State: ALoCoQlURJPFlCBK5DciGAXvs4EbJj87xkMPhvu1m0N+/MLNqxfE5OVvXmoMJ0FS+V51hMNNuaD8
X-Received: by 10.50.143.38 with SMTP id sb6mr2030585igb.44.1435009972370;
	Mon, 22 Jun 2015 14:52:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.149.20 with HTTP; Mon, 22 Jun 2015 14:52:32 -0700 (PDT)
X-Originating-IP: [173.228.107.141]
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
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: 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: Mon, 22 Jun 2015 21:52:54 -0000

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