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 ADFFE9BA for ; Thu, 15 Dec 2016 01:48:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id B9CE5156 for ; Thu, 15 Dec 2016 01:48:39 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id F41D538AB89E; Thu, 15 Dec 2016 01:48:27 +0000 (UTC) X-Hashcash: 1:25:161215:teekhan42@gmail.com::AzoToCsKXxbplY+d:w9h/ X-Hashcash: 1:25:161215:bitcoin-dev@lists.linuxfoundation.org::50waoeBpdi2mhPsA:awXvu From: Luke Dashjr To: "t. khan" Date: Thu, 15 Dec 2016 01:48:23 +0000 User-Agent: KMail/1.13.7 (Linux/4.4.36-gentoo-r1; KDE/4.14.24; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201612150148.23862.luke@dashjr.org> X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD 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 Subject: Re: [bitcoin-dev] BIP - Block75 - Managing max block size as we do difficulty X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 01:48:40 -0000 Please use ASCII quotes in the Title. It is also too long (max size 44=20 characters). Add missing headers: Layer: Consensus (hard fork) Comments-Summary: No comments yet. Comments-URI: TBD Status: Draft Type: Standards Track License: PD It must be made at least technically sound. The BIP talks about adjusting t= he=20 maximum block size, but the specification only affects MAX_BLOCK_BASE_SIZE,= =20 which does not actually affect the max block size at all. Either the=20 specification needs to implement the described goal (adjusting max block si= ze)=20 or the motivation needs to be adjusted to explain why MAX_BLOCK_BASE_SIZE i= s=20 being adjusted. It is missing a section on Backward Compatibility. This should address at=20 least the fact that this is *NOT* backward compatible, and ideally propose = a=20 mechanism for establishing agreement from the entire community for its=20 deployment. Similarly, there is talk of 75%, but the algorithm presented do= es=20 not in fact implement 75%. =46inally, I am about to set BIP 2 to Active, so it would be preferable to= =20 choose a copyright license from the choices in BIP 2. When you're ready, feel free to open a pull request on=20 https://github.com/bitcoin/bips/ with the BIP in mediawiki format, named: bip-tkhan-block75.mediawiki Thanks, Luke On Wednesday, December 14, 2016 7:55:20 PM t. khan wrote: > Hi Luke, >=20 > Following is a BIP for submission. Please let me know if any > modifications/additions are required. >=20 > Thank you, >=20 > -t.k. >=20 > -------- >=20 > BIP: ?? > Title: =E2=80=98Block75=E2=80=99 - Managing max block size the same way w= e do difficulty > Author: t.khan > Created: 2016-12-13 >=20 >=20 > Abstract > Automatic adjustment of max block size with the target of keeping blocks > 75% full, based on the average block size of the previous 2016 blocks. Th= is > would be done on the same schedule as difficulty. >=20 >=20 > Motivation > The every two-week and automatic adjustment of difficulty has proven to be > a reasonably effective and predictable way of managing how quickly blocks > are mined. It works well because humans aren=E2=80=99t involved, except = for > setting the original target of a 10 minute per block average, and therefo= re > it isn=E2=80=99t political or contentious. It=E2=80=99s simply a response= to changing > network resources. >=20 > Bitcoin needs a reasonably effective and predictable way of managing the > maximum block size, which both allows moderate growth and keeps max block > size as small as possible, thereby preventing wild swings in max block si= ze > or transaction fees. >=20 > It=E2=80=99s clear at this point that human beings should not be involved= in the > determination of max block size, just as they=E2=80=99re not involved in = deciding > the difficulty. Any solution to block size scaling which sets an arbitrary > max block size (1MB, 2MB, 8MB, etc.) is by its very design a temporary > solution and should be avoided. Any solution which passes the decision on > to miners/pool operators for a vote will, by its very design, be political > and contentious and should be avoided. >=20 > A permanent solution that is simply a response to changing transaction > volumes is the goal of Block75. >=20 >=20 > Specification > The max block size would be recalculated every 2016 blocks, along with > difficulty, using this simple formula: >=20 > new max block size =3D 1,000KB + (average size of last 2016 blocks - 750K= B) >=20 > Further details: >=20 > MAX_BLOCK_BASE_SIZE =3D 1000000 //this line stays the same > TARGET_CAPACITY =3D 750000 //new line representing 75% >=20 > AVERAGE_OVER_CAP =3D average block size of last 2016 blocks minus > TARGET_CAPACITY >=20 > To check if a block is valid, =E2=89=A4 (MAX_BLOCK_BASE_SIZE + AVERAGE_OV= ER_CAP) >=20 >=20 > Rationale > The 75% full block target was selected as it represents the middle ground > between blocks being too small (average 100% full) and blocks being > unnecessarily large (average 50% full). It can absorb short-term spikes in > transaction volume of up to 33% and also limits the growth of max block > size to 250KB over the previous period. >=20 > The 2016 blocks (two week) period was selected as it has been shown to be > reasonably adaptive to changing network resources. The frequent and gradu= al > adjustments that result from this will be relatively easy for miners and > node operators to predict and adapt to, as any unforeseen consequences wi= ll > be visible well in advance. It also minimizes any effect a malicious party > could have in an attempt to manipulate block size. >=20 > Copyright > This work is placed in the public domain.