Return-Path: <1240902@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D106C937 for ; Fri, 13 Nov 2015 02:56:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B8551AA for ; Fri, 13 Nov 2015 02:56:56 +0000 (UTC) Received: by igcph11 with SMTP id ph11so7443777igc.1 for ; Thu, 12 Nov 2015 18:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Iq3dgNOecCUaftfAdhinQi/fTqzc81GFJzdUWZ5ak8o=; b=iZ5kQBUiWn/QlXWsBh23ZvQhYHZ6Z/E8mAlk0MXbGFemJHLZODJqeB2Wtg8V74gKf1 V/sa2FwgwZ8lCrq9EpVV2Naizkr6A/51eTpU7kD+0rB7g+Z24wqteoYM/+K5RUyRd7zy ErjXjHx5kCjNtOKfJBgNOl3PUg7kCFyS2C0Bw+hNdPk1W0PwkyvxCdtBXIC+D0PjHTVo a6U8gF1ekSNowNtbo88ZtMZ8x967re6rHLKA02luO0O8bEKH5mMII1BVgfdFAL7daikq dR273zr9yxWa3zOmkr524iMowvJegWk8eza7Ut33UJIXiSjJfZE5j3d7WSg6Ibs+bond H/zg== MIME-Version: 1.0 X-Received: by 10.50.59.227 with SMTP id c3mr794949igr.58.1447383415754; Thu, 12 Nov 2015 18:56:55 -0800 (PST) Received: by 10.107.4.138 with HTTP; Thu, 12 Nov 2015 18:56:55 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Nov 2015 10:56:55 +0800 Message-ID: From: Chun Wang <1240902@gmail.com> To: John Sacco Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 02:56:57 -0000 How about these specs: * 1 MB, height < 210000; * 2 MB, 210000 <= height < 420000; * 4 MB, 420000 <= height < 630000; * 8 MB, 630000 <= height < 840000; * 16 MB, 840000 <= height < 1050000; * 32 MB, height >= 1050000. On Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev wrote: > 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 > > 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. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >