{"type":"rich","version":"1.0","author_name":"npub1edz8qyleqfqddckyjs0erkqysv2n76fwatw32nehpm5k7gertf4shmqjxc","author_url":"https://nostr.ae/npub1edz8qyleqfqddckyjs0erkqysv2n76fwatw32nehpm5k7gertf4shmqjxc","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-11-13\n📝 Original message:How about these specs:\n* 1 MB, height \u003c 210000;\n* 2 MB, 210000 \u003c= height \u003c 420000;\n* 4 MB, 420000 \u003c= height \u003c 630000;\n* 8 MB, 630000 \u003c= height \u003c 840000;\n* 16 MB, 840000 \u003c= height \u003c 1050000;\n* 32 MB, height \u003e= 1050000.\n\n\nOn Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Hi Devs,\n\u003e\n\u003e\n\u003e Please consider the draft proposal below for peer review.\n\u003e\n\u003e\n\u003e Thanks,\n\u003e\n\u003e\n\u003e John\n\u003e\n\u003e\n\u003e BIP\n\u003e\n\u003e   BIP: ?\n\u003e\n\u003e   Title: Block size doubles at each reward halving with max block size of\n\u003e 32M\n\u003e\n\u003e   Author: John Sacco \u003cjohnsock at gmail.com\u003e\n\u003e\n\u003e   Status: Draft\n\u003e\n\u003e   Type: Standards Track\n\u003e\n\u003e   Created: 2015-11-11\n\u003e\n\u003e Abstract\n\u003e\n\u003e Change max block size to 2MB at next block subsidy halving, and double the\n\u003e block size at each subsidy halving until reaching 32MB.\n\u003e\n\u003e Copyright\n\u003e\n\u003e This proposal belongs in the public domain. Anyone can use this text for any\n\u003e purpose with proper attribution to the author.\n\u003e\n\u003e Motivation\n\u003e\n\u003e 1.    Gradually restores block size to the default 32 MB setting originally\n\u003e implemented by Satoshi.\n\u003e\n\u003e 2.    Initial increase to 2MB at block halving in July 2016 would have\n\u003e minimal impact to existing nodes running on most hardware and networks.\n\u003e\n\u003e 3.    Long term solution that does not make enthusiastic assumptions\n\u003e regarding future bandwidth and storage availability estimates.\n\u003e\n\u003e 4.    Maximum block size of 32MB allows peak usage of ~100 tx/sec by year\n\u003e 2031.\n\u003e\n\u003e 5.    Exercise network upgrade procedure during subsidy reward halving, a\n\u003e milestone event with the goal of increasing awareness among miners and node\n\u003e operators.\n\u003e\n\u003e Specification\n\u003e\n\u003e 1.    Increase the maximum block size to 2MB when block 630,000 is reached\n\u003e and 75% of the last 1,000 blocks have signaled support.\n\u003e\n\u003e 2.    Increase maximum block size to 4MB at block 840,000.\n\u003e\n\u003e 3.    Increase maximum block size to 8MB at block 1,050,000.\n\u003e\n\u003e 4.    Increase maximum block size to 16MB at block 1,260,000.\n\u003e\n\u003e 5.    Increase maximum block size to 32MB at block 1,470,000.\n\u003e\n\u003e Backward compatibility\n\u003e\n\u003e All older clients are not compatible with this change. The first block\n\u003e larger than 1M will create a network partition excluding not-upgraded\n\u003e network nodes and miners.\n\u003e\n\u003e Rationale\n\u003e\n\u003e While more comprehensive solutions are developed, an increase to the block\n\u003e size is needed to continue network growth. A longer term solution is needed\n\u003e to prevent complications associated with additional hard forks. It should\n\u003e also increase at a gradual rate that retains and allows a large distribution\n\u003e of full nodes.  Scheduling this hard fork to occur no earlier than the\n\u003e subsidy halving in 2016 has the goal of simplifying the communication\n\u003e outreach needed to achieve consensus, while also providing a buffer of time\n\u003e to make necessary preparations.\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e"}