rich1.0npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uhttps://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0unjumphttps://nostr.ae📅 Original date posted:2015-06-22 📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/fb29411c/attachment.html>