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