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