Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Mark Friedenbach <mark@friedenbach.org>]

[-- Attachment #1: Type: text/plain, Size: 5672 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 8909 bytes --]