rich1.0npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwhttps://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwnjumphttps://nostr.ae📅 Original date posted:2015-06-22 📝 Original message: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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/15ca6d1f/attachment-0001.html>