Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6EF0E259 for ; Mon, 17 Aug 2015 10:51:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8976E8 for ; Mon, 17 Aug 2015 10:51:46 +0000 (UTC) Received: by ykdt205 with SMTP id t205so122418067ykd.1 for ; Mon, 17 Aug 2015 03:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tKTE0LSQoFuFbdXmrnY10wrpWPMvPoJubWAetibu0A8=; b=ifcqggvRB8fK8/khkEOi/Ra117B2zXUHjR7S1QhiRh/7cVDTUN4xNRqMShlJHyzCJd lbJ4s7mML4BrgdnkDDYEuP0nNRgJpqTakvyjJAfvqDBQZ8EHVofMyf3bwNQbuhOCqzIu HJvrPWGpC6WIVE/Ec0HAugUAyY+iShF6oHqcGn8kEiMDZm9AKa1aTPdNv+5Cq5+QCKXj AYarflnGiTDDSdQeMpio4E9RoJvnQhgbt1PugoJdxWI+kH7p5sMK8Rerb5P+65rk6Q/g fScJ0t9xlr8EZTxHB4/fmgjW37ppMcYSP1nLVg293BYsdVcH+IjqA2XsKX/F8H53H5BC /5PA== X-Received: by 10.13.254.1 with SMTP id o1mr682569ywf.88.1439808705871; Mon, 17 Aug 2015 03:51:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.94.132 with HTTP; Mon, 17 Aug 2015 03:51:26 -0700 (PDT) In-Reply-To: <55D1B077.6070208@gmail.com> References: <55D1B077.6070208@gmail.com> From: Btc Drak Date: Mon, 17 Aug 2015 11:51:26 +0100 Message-ID: To: Patrick Strateman Content-Type: multipart/alternative; boundary=94eb2c0809f4754534051d7f96b4 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, HTML_MESSAGE, HTML_OBFUSCATE_05_10, RCVD_IN_DNSWL_LOW autolearn=no 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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Mon, 17 Aug 2015 10:51:48 -0000 --94eb2c0809f4754534051d7f96b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Nobody is going to click that... I guess I am nobody. Here's a copy of the text:- *Dynamically Controlled Bitcoin Block Size Max Cap * *Assumption*: This article is for those, who already understand the bitcoin protocol and aware of the block size controversy. Details of the problem statement can be found in BIP 100 . Satoshi's opinion regarding block size can be found here . I will = be directly going into the solution without explaining the problem in details. *Solution*: Difficulty changes at every 2016 block, i.e. at every 2016 block each full node does a calculation to find the next target. We will do just another calculation here. Nodes will also calculate what % of blocks in the last difficulty period is higher than 90% of the maximum block size, which is 1 MB for now. If it is found that more than 90% blocks in the last difficulty period is higher than 90% of the maximum block size, then double the maximum block size. If not, then calculate what % of blocks in the last difficulty period is less than 50% of the maximum block size. If it is higher than 90%, then half the maximum block size. If none of the above condition satisfies, keep the maximum block size as it is. Please note that, while calculating the % of blocks, it is better to take into account the first 2000 of the 2016, than the whole of 2016. This helps to avoid the calculation mistake if some of the last few blocks get orphaned. *Reasoning*: This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty. *Other Solutions of this Problem*:- Making Decentralized Economic Policy - by Jeff Garzik Elastic block cap with rollover penalties =E2=80=93 by Meni Rosen= feld Increase maximum block size - by Gavin Andresen Block size following technological growth - by Pieter Wuille The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments - by Joseph Poon & Thaddeus Dryja Please share your opinion regarding this solution below. For mail communication, feel free to write me at bitcoin [at] upalc.com. > On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote: > > I have tried to solve the maximum block size debate, depending on the > previous block size calculation. > > Requesting for comment - http://upalc.com/maxblocksize.php > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c0809f4754534051d7f96b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bi= tcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:
> Nobody is going to= click that...

I guess I am nobody. Here's a copy of the text:-<= br>

=

Assumption: This article is f= or those, who already understand the bitcoin protocol and aware of the bloc= k size controversy. Details of the problem statement can be found in=C2=A0<= a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf"= target=3D"_blank">BIP 100. Satoshi's opinion regarding block size = can be found=C2=A0here. I will be directly going in= to the solution without explaining the problem in details.


So= lution: Difficulty changes at every 2016 block, i.e. at every 2016 bloc= k each full node does a calculation to find the next target. We will do jus= t another calculation here. Nodes will also calculate what % of blocks in t= he last difficulty period is higher than 90% of the maximum block size, whi= ch is 1 MB for now. If it is found that more than 90% blocks in the last di= fficulty period is higher than 90% of the maximum block size, then double t= he maximum block size. If not, then calculate what % of blocks in the last = difficulty period is less than 50% of the maximum block size. If it is high= er than 90%, then half the maximum block size. If none of the above conditi= on satisfies, keep the maximum block size as it is.

Please note that= , while calculating the % of blocks, it is better to take into account the = first 2000 of the 2016, than the whole of 2016. This helps to avoid the cal= culation mistake if some of the last few blocks get orphaned.


Reasoning: This solution is derived directly from the indication of th= e problem. If transaction volume increases, then we will naturally see bigg= er blocks. On the contrary, if there are not enough transaction volume, but= maximum block size is high, then only few blocks may sweep the mempool. He= nce, if block size is itself taken into consideration, then maximum block s= ize can most rationally be derived. Moreover, this solution not only increa= ses, but also decreases the maximum block size, just like difficulty.

Other Solutions of this Problem:-

M= aking Decentralized Economic Policy=C2=A0- by Jeff Garzik

E= lastic block cap with rollover penalties=C2=A0=E2=80=93 by Meni Rosenfe= ld

Increase maximum block size=C2=A0- by Gavin= Andresen

Block size following technological growth=C2=A0- = by Pieter Wuille=C2=A0

The Bitcoin Lightning Network: Scala= ble Off-Chain Instant Payments=C2=A0- by Joseph Poon & Thaddeus Dry= ja=C2=A0


Please share your opinion regarding this solution below= . For mail communication, feel free to write me at bitcoin [at] upalc.com.



> = On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
>
= > I have tried to solve the maximum block size debate, depending on the<= br>> previous block size calculation.
>
> Requesting for com= ment - http://upalc.com/maxbl= ocksize.php
>
>
> ___________________________________= ____________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> ________________________________________= _______
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
--94eb2c0809f4754534051d7f96b4--