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