From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D4DCE8F0 for ; Thu, 12 Nov 2015 23:47:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 42893124 for ; Thu, 12 Nov 2015 23:47:32 +0000 (UTC) Received: by obbbj7 with SMTP id bj7so42607365obb.1 for ; Thu, 12 Nov 2015 15:47:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Grbf++FdF2BCf/VzeETZxo3hnqXrbdwTUHbdVJieXxE=; b=yyK+XR7m3k2W7/nuuW2gt4flL5P9Uo+9xavY8gKrtLTn0E91CA2XdH8aQ1G4Q5v2u8 +9Z31z/AnwMg6iAFlfJSpzod/pQI3PPSDTgDYc4PqsNDjFRvYu1RXECf2m6YVtZJW6V0 e0AxGW1dl6CKiC6G2d+DjXVGFpWQBn3x56mZKumLOGtayd04FSPLlC8WAURyqlDiPBga VyvFEioJOzgos17qcvVkOPx9yoMRp2wU7KJT3e9LGBWYfFvtHdQSvvAgxtmpRbnnyRu0 NOXguzglyj7XKetdxOgZSvO0mB5sfaoLLWtQLpjpK/WDlSs5etmbfl16emTXQrOown4+ MHig== MIME-Version: 1.0 X-Received: by 10.60.164.73 with SMTP id yo9mr10556220oeb.33.1447372051588; Thu, 12 Nov 2015 15:47:31 -0800 (PST) Received: by 10.202.48.20 with HTTP; Thu, 12 Nov 2015 15:47:31 -0800 (PST) Date: Thu, 12 Nov 2015 18:47:31 -0500 Message-ID: From: John Sacco To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=047d7b450b7efe2ca805246090e7 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 X-Mailman-Approved-At: Fri, 13 Nov 2015 00:01:04 +0000 Subject: [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: Thu, 12 Nov 2015 23:47:32 -0000 --047d7b450b7efe2ca805246090e7 Content-Type: text/plain; charset=UTF-8 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. --047d7b450b7efe2ca805246090e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Devs,=C2=A0


Please consider t= he draft proposal below for peer review. =C2=A0


Thanks,


John


BIP

= =C2=A0 BIP: ?

= =C2=A0 Title: Block size doubles at each reward halving with max block size of 32M

= =C2=A0 Author: John Sacco <johnsock@gmail.com>

= =C2=A0 Status: Draft

= =C2=A0 Type: Standards Track

= =C2=A0 Created: 2015-11-11

Abst= ract

Change max block size to = 2MB at next block subsidy halving, and double the block size at each subsidy halving until reaching 32MB.

Copy= right

This proposal belongs in = the public domain. Anyone can use this text for any purpose with proper attribution to the author.=C2=A0

Moti= vation

1.= =C2=A0=C2=A0=C2=A0 Gradually restores block size to the default 32 MB setting originally implemented by Satoshi.<= /span>

2.= =C2=A0=C2=A0=C2=A0 Initial increase to 2MB at block halving in July 2016 would have minimal impact to existing nod= es running on most hardware and networks.

3.= =C2=A0=C2=A0=C2=A0 Long term solution that does not make enthusiastic assumptions regarding future bandwidth and storage availability estimates. =C2=A0

4.= =C2=A0=C2=A0=C2=A0 Maximum block size of 32MB allows peak usage of ~100 tx/sec by year 2031. =C2=A0

5.= =C2=A0=C2=A0=C2=A0 Exercise network upgrade procedure during subsidy reward halving, a milestone event with the goal of increasing awareness among miners and node operators. =C2=A0=

Spec= ification

1.=C2=A0=C2=A0=C2=A0 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.=C2=A0=C2=A0=C2=A0 Increase maximum block size to 4MB at block 840,000.

3.=C2=A0=C2=A0=C2=A0 Increase maximum block size to 8MB at block 1,050,000.

4.=C2=A0=C2=A0=C2=A0 Increase maximum block size to 16MB at block 1,260,000.

5.=C2=A0=C2=A0=C2=A0 Increase maximum block size to 32MB at block 1,470,000.

Back= ward 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.

Rati= onale

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.=C2=A0 Scheduling this hard fork to occur no ear= lier than the subsidy halving in 2016 has the goal of simplifying the communicat= ion outreach needed to achieve consensus, while also providing a buffer of time= to make necessary preparations.=C2=A0

--047d7b450b7efe2ca805246090e7--