rich1.0npub1vt9mgqkjw57ccqqp9kagu32tghtyt94urnr38sagmashfyw7xpcs64zu72https://nostr.ae/npub1vt9mgqkjw57ccqqp9kagu32tghtyt94urnr38sagmashfyw7xpcs64zu72njumphttps://nostr.ae📅 Original date posted:2015-11-12 📝 Original message:Hi Devs, Please consider the draft proposal below for peer review. Thanks, John BIP BIP: ? Title: Block size doubles at each reward halving with max block size of 32M Author: John Sacco <johnsock at gmail.com> Status: Draft Type: Standards Track Created: 2015-11-11 Abstract Change max block size to 2MB at next block subsidy halving, and double the block size at each subsidy halving until reaching 32MB. Copyright This proposal belongs in the public domain. Anyone can use this text for any purpose with proper attribution to the author. Motivation 1. Gradually restores block size to the default 32 MB setting originally implemented by Satoshi. 2. Initial increase to 2MB at block halving in July 2016 would have minimal impact to existing nodes running on most hardware and networks. 3. Long term solution that does not make enthusiastic assumptions regarding future bandwidth and storage availability estimates. 4. Maximum block size of 32MB allows peak usage of ~100 tx/sec by year 2031. 5. Exercise network upgrade procedure during subsidy reward halving, a milestone event with the goal of increasing awareness among miners and node operators. Specification 1. Increase the maximum block size to 2MB when block 630,000 is reached and 75% of the last 1,000 blocks have signaled support. 2. Increase maximum block size to 4MB at block 840,000. 3. Increase maximum block size to 8MB at block 1,050,000. 4. Increase maximum block size to 16MB at block 1,260,000. 5. Increase maximum block size to 32MB at block 1,470,000. Backward compatibility All older clients are not compatible with this change. The first block larger than 1M will create a network partition excluding not-upgraded network nodes and miners. Rationale While more comprehensive solutions are developed, an increase to the block size is needed to continue network growth. A longer term solution is needed to prevent complications associated with additional hard forks. It should also increase at a gradual rate that retains and allows a large distribution of full nodes. Scheduling this hard fork to occur no earlier than the subsidy halving in 2016 has the goal of simplifying the communication outreach needed to achieve consensus, while also providing a buffer of time to make necessary preparations. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151112/c00ed906/attachment-0001.html>