Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 14722AB2 for ; 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 ; Mon, 22 Jun 2015 21:52:52 +0000 (UTC) Received: by igbiq7 with SMTP id iq7so63001658igb.1 for ; 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: References: From: Mark Friedenbach Date: Mon, 22 Jun 2015 14:52:32 -0700 Message-ID: To: Gavin Andresen 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 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
Can you please add a discussion of the tradeoffs of decent= ralization 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 implemen= ted increase-the-maximum-block-size code, so here it is. It also lives at: = =C2=A0 https://github.com/gavinandresen/bips/blob= /blocksize/bip-8MB.mediawiki

I don'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




=C2=A0 BIP: ??
=C2=A0 Title: Increase Maximum Block Size
=C2=A0 Author: Gavin Andresen <gavinandresen@gmail.com>
<= div class=3D"gmail_extra">=C2=A0 Status: Draft
=C2=A0 Type: Standards Track
=C2=A0 Cre= ated: 2015-06-22

=3D=3DAbstract=3D=3D

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

=3D=3DMotivation=3D=3D

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.

=3D=3DSpecification= =3D=3D

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), 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's ti= mestamp. 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:

=C2=A0 =C2=A0 func= tion max_block_size(block_timestamp):

<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time_start =3D = 1452470400
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time= _double =3D 60*60*24*365*2
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 size_start =3D 8000000
=C2=A0= =C2=A0 =C2=A0 =C2=A0 if block_timestamp >=3D time_start+time_double*10<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r= eturn size_start * 2^10

=C2=A0 =C2=A0 =C2=A0 =C2=A0 // Piecewise-linear-between-d= oublings growth:
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 time_delta =3D block_timestamp - t_start
=C2=A0 =C2=A0 =C2=A0 =C2=A0 doublings =3D time_delta / time_double
<= div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 remainder =3D time_de= lta % time_double
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 interpolate =3D (size_start * 2^doublings * remainder) / time_double
=C2=A0 =C2=A0 =C2=A0 =C2=A0 max_size =3D size= _start * 2^doublings + interpolate

=C2=A0 =C2=A0 =C2=A0 =C2=A0 return max_size

=3D=3DDe= ployment=3D=3D

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.

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= '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.

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.


=3D=3DRationale= =3D=3D

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

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.

Calculations are based on timestamps and not blockchain height beca= use a timestamp is part of every block's header. This allows implementa= tions to know a block's maximum size after they have downloaded it'= s header, but before downloading any transactions.

The deployment plan is taken f= rom 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 ov= er a blocksize increase. The version number scheme is designed to be compat= ible with Pieter's Wuille's proposed "Version bits" BIP.<= /div>

TODO: = summarize objections/arguments from http://gavinandresen.ninja= /time-to-roll-out-bigger-blocks.

TODO: describe other proposals and their adv= antages/disadvantages over this proposal.
<= br>

= =3D=3DCompatibility=3D=3D

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.

Simplified Payment Verification software is not affected, unle= ss it makes assumptions about the maximum depth of a transaction's merk= le branch based on the minimum size of a transaction and the maximum block = size.

= =3D=3DImplementation=3D=3D



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a1135ffb8a718330519224b02--