{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-22\n📝 Original message:I promised to write a BIP after I'd implemented\nincrease-the-maximum-block-size code, so here it is. It also lives at:\nhttps://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki\n\nI don't expect any proposal to please everybody; there are unavoidable\ntradeoffs to increasing the maximum block size. I prioritize implementation\nsimplicity -- it is hard to write consensus-critical code, so simpler is\nbetter.\n\n\n\n\n  BIP: ??\n  Title: Increase Maximum Block Size\n  Author: Gavin Andresen \u003cgavinandresen at gmail.com\u003e\n  Status: Draft\n  Type: Standards Track\n  Created: 2015-06-22\n\n==Abstract==\n\nThis BIP proposes replacing the fixed one megabyte maximum block size with\na maximum size that grows over time at a predictable rate.\n\n==Motivation==\n\nTransaction volume on the Bitcoin network has been growing, and will soon\nreach the one-megabyte-every-ten-minutes limit imposed by the one megabyte\nmaximum block size. Increasing the maximum size reduces the impact of that\nlimit on Bitcoin adoption and growth.\n\n==Specification==\n\nAfter deployment on the network (see the Deployment section for details),\nthe maximum allowed size of a block on the main network shall be calculated\nbased on the timestamp in the block header.\n\nThe maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11\n00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000\nseconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC\n(timestamp 2083190400). The maximum size of blocks in between doublings\nwill increase linearly based on the block's timestamp. The maximum size of\nblocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.\n\nExpressed in pseudo-code, using integer math:\n\n    function max_block_size(block_timestamp):\n\n        time_start = 1452470400\n        time_double = 60*60*24*365*2\n        size_start = 8000000\n        if block_timestamp \u003e= time_start+time_double*10\n            return size_start * 2^10\n\n        // Piecewise-linear-between-doublings growth:\n        time_delta = block_timestamp - t_start\n        doublings = time_delta / time_double\n        remainder = time_delta % time_double\n        interpolate = (size_start * 2^doublings * remainder) / time_double\n        max_size = size_start * 2^doublings + interpolate\n\n        return max_size\n\n==Deployment==\n\nDeployment shall be controlled by hash-power supermajority vote (similar to\nthe technique used in BIP34), but the earliest possible activation time is\n2016-01-11 00:00:00 UTC.\n\nActivation is achieved when 750 of 1,000 consecutive blocks in the best\nchain have a version number with bits 3 and 14 set (0x20000004 in hex). The\nactivation time will be the timestamp of the 750'th block plus a two week\n(1,209,600 second) grace period to give any remaining miners or services\ntime to upgrade to support larger blocks. If a supermajority is achieved\nmore than two weeks before 2016-01-11 00:00:00 UTC, the activation time\nwill be 2016-01-11 00:00:00 UTC.\n\nBlock version numbers are used only for activation; once activation is\nachieved, the maximum block size shall be as described in the specification\nsection, regardless of the version number of the block.\n\n\n==Rationale==\n\nThe initial size of 8,000,000 bytes was chosen after testing the current\nreference implementation code with larger block sizes and receiving\nfeedback from miners stuck behind bandwidth-constrained networks (in\nparticular, Chinese miners behind the Great Firewall of China).\n\nThe doubling interval was chosen based on long-term growth trends for CPU\npower, storage, and Internet bandwidth. The 20-year limit was chosen\nbecause exponential growth cannot continue forever.\n\nCalculations are based on timestamps and not blockchain height because a\ntimestamp is part of every block's header. This allows implementations to\nknow a block's maximum size after they have downloaded it's header, but\nbefore downloading any transactions.\n\nThe deployment plan is taken from Jeff Garzik's proposed BIP100 block size\nincrease, and is designed to give miners, merchants, and\nfull-node-running-end-users sufficient time to upgrade to software that\nsupports bigger blocks. A 75% supermajority was chosen so that one large\nmining pool does not have effective veto power over a blocksize increase.\nThe version number scheme is designed to be compatible with Pieter's\nWuille's proposed \"Version bits\" BIP.\n\nTODO: summarize objections/arguments from\nhttp://gavinandresen.ninja/time-to-roll-out-bigger-blocks.\n\nTODO: describe other proposals and their advantages/disadvantages over this\nproposal.\n\n\n==Compatibility==\n\nThis is a hard-forking change to the Bitcoin protocol; anybody running code\nthat fully validates blocks must upgrade before the activation time or they\nwill risk rejecting a chain containing larger-than-one-megabyte blocks.\n\nSimplified Payment Verification software is not affected, unless it makes\nassumptions about the maximum depth of a transaction's merkle branch based\non the minimum size of a transaction and the maximum block size.\n\n==Implementation==\n\nhttps://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/15ca6d1f/attachment-0001.html\u003e"}