From mboxrd@z Thu Jan 1 00:00:00 1970 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 85A2CB01 for ; Tue, 25 Aug 2015 09:19:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AEDF1129 for ; Tue, 25 Aug 2015 09:19:28 +0000 (UTC) Received: by iods203 with SMTP id s203so179292433iod.0 for ; Tue, 25 Aug 2015 02:19:28 -0700 (PDT) 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=viruWsbQ/2X9LtfujVp0uu2HC/p5U7TsN+bRwiutBAI=; b=kqgoJN7VRnobwjdLRUnlMctTsiYKHezqxHwlX47xNwzKX5PISCa/r/zhhjLlyuA7h5 k01HlhKJe4BB+HHcrsJJsj5rURHb4aQr5urDJQO4QnwNJlvRGyOVFZbYnB5zmVIGWM17 Q3ZxoCkKZlKFK1+rAEJGBW0xSwiu8xcMBjqnOfv/+BSNo08BrjnVZizMYECMMbbENaQl DYKqL6yEwxtNkCXAUTYXo9zd+BIqB+S8XdUvOD7zdMYCKg9FnvOrYKYp9iQ4yOLc/sWm S48jKBTCfHb5NxVwX8LIYdlg3U1Y/H1dHErWZzyiOOYtlWoQ+dECq6LBCvFAWcHglpMo X+NA== MIME-Version: 1.0 X-Received: by 10.107.19.81 with SMTP id b78mr25356522ioj.36.1440494368174; Tue, 25 Aug 2015 02:19:28 -0700 (PDT) Received: by 10.107.10.159 with HTTP; Tue, 25 Aug 2015 02:19:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Aug 2015 17:19:28 +0800 Message-ID: From: Chun Wang <1240902@gmail.com> To: Upal Chakraborty 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, greg@xiph.org Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft] 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: Tue, 25 Aug 2015 09:19:29 -0000 Proposal 1 looks good, but tx fee collected can be manipulated by miners. I like the idea next block collect the tx fee from previous block. On Tue, Aug 25, 2015 at 5:07 PM, Upal Chakraborty via bitcoin-dev wrote: > Github: > https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki > > 
>   BIP: 1xx
>   Title: Dynamically Controlled Bitcoin Block Size Max Cap
>   Author: Upal Chakraborty 
>   Status: Draft
>   Type: Standards Track
>   Created: 2015-08-24
>
> > ==Abstract== > > This BIP proposes replacing the fixed one megabyte maximum block size with a > dynamically controlled maximum block size that may increase or decrease with > difficulty change depending on various network factors. I have two proposals > regarding this... > > i. Depending only on previous block size calculation. > > ii. Depending on previous block size calculation and previous Tx fee > collected by miners. > > ==Motivation== > > With increased adoption, transaction volume on bitcoin network is bound to > grow. If the one megabyte max cap is not changed to a flexible one which > changes itself with changing network demand, then adoption will hamper and > bitcoin's growth may choke up. Following graph shows the change in average > block size since inception... > > https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address= > > ==Specification== > > ===Proposal 1 : Depending only on previous block size calculation=== > > If more than 50% of block's size, found in the first 2000 of the last > difficulty period, is more than 90% MaxBlockSize > Double MaxBlockSize > Else if more than 90% of block's size, found in the first 2000 of the last > difficulty period, is less than 50% MaxBlockSize > Half MaxBlockSize > Else > Keep the same MaxBlockSize > > ===Proposal 2 : Depending on previous block size calculation and previous Tx > fee collected by miners=== > > TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 > blocks in last 2 difficulty period > TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 > blocks in last 2 difficulty period (This actually includes 8 blocks from > last but one difficulty) > > TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks > in last 2 difficulty period > TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in > last 2 difficulty period (This actually includes 8 blocks from last but one > difficulty) > > If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > > TotalBlockSizeInLastButOneDifficulty) ) > MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / > TotalBlockSizeInLastButOneDifficulty > Else If ( ( (Sum of first 4016 block size in last 2 difficulty > period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < > TotalBlockSizeInLastButOneDifficulty) ) > MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / > TotalBlockSizeInLastButOneDifficulty > Else > Keep the same MaxBlockSize > > ==Rationale== > > These two proposals have been derived after discussion on > [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and > [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html > bitcoin-dev mailing list]. The original idea and its evolution in the light > of various arguements can be found [http://upalc.com/maxblocksize.php here]. > > ===Proposal 1 : Depending only on previous block size calculation=== > > 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. > > ===Proposal 2 : Depending on previous block size calculation and previous Tx > fee collected by miners=== > > This solution takes care of stable mining subsidy. It will not increase > maximum block size, if Tx fee collection is not increasing and thereby > creating a Tx fee pressure on the market. On the other hand, though the > block size max cap is dynamically controlled, it is very difficult to game > by any party because the increase or decrease of block size max cap will > take place in the same ratio of average block size increase or decrease. > > ==Compatibility== > > This is a hard-forking change to the Bitcoin protocol; anybody running code > that fully validates blocks must upgrade before the activation time or they > will risk rejecting a chain containing larger-than-one-megabyte blocks. > > ==Other solutions considered== > > [http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Making > Decentralized Economic Policy] - by Jeff Garzik > > [https://bitcointalk.org/index.php?topic=1078521.0 Elastic block cap with > rollover penalties] - by Meni Rosenfeld > > [https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki Increase > maximum block size] - by Gavin Andresen > > [https://gist.github.com/sipa/c65665fc360ca7a176a6 Block size following > technological growth] - by Pieter Wuille > > [https://lightning.network/lightning-network-paper.pdf The Bitcoin Lightning > Network: Scalable Off-Chain Instant Payments] - by Joseph Poon & Thaddeus > Dryja > > ==Deployment== > > If consensus is achieved, deployment can be made at a future block number at > which difficulty will change. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >