Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BD1D7EFF for ; Thu, 27 Aug 2015 15:09:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 27D6B188 for ; Thu, 27 Aug 2015 15:09:19 +0000 (UTC) Received: by ignq3 with SMTP id q3so11092396ign.1 for ; Thu, 27 Aug 2015 08:09:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oZ4bsAnKFqSJF+d556qd1mIPzKBsodwtDl/amFbiQJI=; b=iOniR5LdSewYn0W9EhxqGP5tU958M3iY+HvauB6ysadqNMsB7SW812lbFmt92NwGXy Z17IS7F851cE0TC9q+DwJR6U5neHkrzzdKqKH/SufJv6SMjXLk5IteaimUrRMlf7XTIK 8oB51cKZGfKpLg1URGY/ltKUN360Aoq4gSB02LJQ9DLX9BA/7G/8BINiHneuVvy+8eSN AHwKL5su5mwRsLnQitIaTLphOlx6+/4O2s/l8SGw7wPEGqeE+/XMj84elEffy+3HxsWg 9KvDNSbYN5Eb9a6DQXR0FZGLiO9qS9AfKw81dRPKrfo/9MLZS92LyrgpyWjVYB9a5uI2 aceA== X-Gm-Message-State: ALoCoQke5q41FLAW4+SQyf5d9DxCxBcl0vew1k1bYNMctqTQrn13ZQm/+XM9Uw+BQ84rg7LFXT4q MIME-Version: 1.0 X-Received: by 10.50.79.202 with SMTP id l10mr9817407igx.7.1440688158341; Thu, 27 Aug 2015 08:09:18 -0700 (PDT) Received: by 10.107.18.155 with HTTP; Thu, 27 Aug 2015 08:09:18 -0700 (PDT) X-Originating-IP: [115.187.37.59] In-Reply-To: References: Date: Thu, 27 Aug 2015 20:39:18 +0530 Message-ID: From: Upal Chakraborty To: Chun Wang <1240902@gmail.com> Content-Type: multipart/alternative; boundary=089e0122aaeee92291051e4c5970 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_WEB 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 , 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: Thu, 27 Aug 2015 15:09:30 -0000 --089e0122aaeee92291051e4c5970 Content-Type: text/plain; charset=UTF-8 Proposal 1 does not deal with Tx fee. Proposal 2 does. According to proposal 2, miners wont be able to increase or decrease Max Block Size only by manipulating Tx fee. They have to manipulate... i. Tx fee of ~4000 blocks. ii. Block size of ~4000 blocks. I never proposed *next block collects Tx fee from previous block*. Not sure what you mean here! On Tue, Aug 25, 2015 at 2:49 PM, Chun Wang <1240902@gmail.com> wrote: > 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 > > > --089e0122aaeee92291051e4c5970 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Proposal 1 do= es not deal with Tx fee. Proposal 2 does. According to proposal 2, miners w= ont be able to increase or decrease Max Block Size only by manipulating Tx = fee. They have to manipulate...
i. Tx fee of ~4000 blocks.
ii. Block size of ~4000 blocks.

I never= proposed=C2=A0next block collects Tx fee from previous block. Not s= ure what you mean here!

On Tue, Aug 25, 2015 at 2:49 PM, Chun Wang <1240902@gmai= l.com> wrote:
Proposal 1 lo= oks 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
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> Github:
> https://gi= thub.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki=
>
> <pre>
>=C2=A0 =C2=A0BIP: 1xx
>=C2=A0 =C2=A0Title: Dynamically Controlled Bitcoin Block Size Max Cap >=C2=A0 =C2=A0Author: Upal Chakraborty <bitcoin@upalc.com>
>=C2=A0 =C2=A0Status: Draft
>=C2=A0 =C2=A0Type: Standards Track
>=C2=A0 =C2=A0Created: 2015-08-24
> </pre>
>
> =3D=3DAbstract=3D=3D
>
> This BIP proposes replacing the fixed one megabyte maximum block size = with a
> dynamically controlled maximum block size that may increase or decreas= e with
> difficulty change depending on various network factors. I have two pro= posals
> regarding this...
>
> i. Depending only on previous block size calculation.
>
> ii. Depending on previous block size calculation and previous Tx fee > collected by miners.
>
> =3D=3DMotivation=3D=3D
>
> With increased adoption, transaction volume on bitcoin network is boun= d to
> grow. If the one megabyte max cap is not changed to a flexible one whi= ch
> 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=3Dall&showDataPoints= =3Dfalse&daysAverageString=3D1&show_header=3Dtrue&scale=3D0&= ;address=3D
>
> =3D=3DSpecification=3D=3D
>
> =3D=3D=3DProposal 1 : Depending only on previous block size calculatio= n=3D=3D=3D
>
>=C2=A0 =C2=A0If more than 50% of block's size, found in the first 2= 000 of the last
> difficulty period, is more than 90% MaxBlockSize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Double MaxBlockSize
>=C2=A0 =C2=A0Else if more than 90% of block's size, found in the fi= rst 2000 of the last
> difficulty period, is less than 50% MaxBlockSize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Half MaxBlockSize
>=C2=A0 =C2=A0Else
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Keep the same MaxBlockSize
>
> =3D=3D=3DProposal 2 : Depending on previous block size calculation and= previous Tx
> fee collected by miners=3D=3D=3D
>
>=C2=A0 =C2=A0TotalBlockSizeInLastButOneDifficulty =3D Sum of all Block = size of first 2008
> blocks in last 2 difficulty period
>=C2=A0 =C2=A0TotalBlockSizeInLastDifficulty =3D Sum of all Block size o= f second 2008
> blocks in last 2 difficulty period (This actually includes 8 blocks fr= om
> last but one difficulty)
>
>=C2=A0 =C2=A0TotalTxFeeInLastButOneDifficulty =3D Sum of all Tx fees of= first 2008 blocks
> in last 2 difficulty period
>=C2=A0 =C2=A0TotalTxFeeInLastDifficulty =3D Sum of all Tx fees of secon= d 2008 blocks in
> last 2 difficulty period (This actually includes 8 blocks from last bu= t one
> difficulty)
>
>=C2=A0 =C2=A0If ( ( (Sum of first 4016 block size in last 2 difficulty = period)/4016 >
> 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty >
> TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty = >
> TotalBlockSizeInLastButOneDifficulty) )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MaxBlockSize =3D TotalBlockSizeInLastDifficu= lty * MaxBlockSize /
> TotalBlockSizeInLastButOneDifficulty
>=C2=A0 =C2=A0Else If ( ( (Sum of first 4016 block size in last 2 diffic= ulty
> period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty &l= t;
> TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty = <
> TotalBlockSizeInLastButOneDifficulty) )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MaxBlockSize =3D TotalBlockSizeInLastDifficu= lty * MaxBlockSize /
> TotalBlockSizeInLastButOneDifficulty
>=C2=A0 =C2=A0Else
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Keep the same MaxBlockSize
>
> =3D=3DRationale=3D=3D
>
> These two proposals have been derived after discussion on
> [https://bitcointalk.org/index.php?topic= =3D1154536.0 BitcoinTalk] and
> [http://lists.lin= uxfoundation.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/maxblocks= ize.php here].
>
> =3D=3D=3DProposal 1 : Depending only on previous block size calculatio= n=3D=3D=3D
>
> 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 bl= ock
> size is itself taken into consideration, then maximum block size can m= ost
> rationally be derived. Moreover, this solution not only increases, but= also
> decreases the maximum block size, just like difficulty.
>
> =3D=3D=3DProposal 2 : Depending on previous block size calculation and= previous Tx
> fee collected by miners=3D=3D=3D
>
> This solution takes care of stable mining subsidy. It will not increas= e
> 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 th= e
> 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 wi= ll
> take place in the same ratio of average block size increase or decreas= e.
>
> =3D=3DCompatibility=3D=3D
>
> 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= .
>
> =3D=3DOther solutions considered=3D=3D
>
> [http://gtf.org/garzik/bitcoin/= BIP100-blocksizechangeproposal.pdf Making
> Decentralized Economic Policy] - by Jeff Garzik
>
> [https://bitcointalk.org/index.php?topic= =3D1078521.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/c65665fc360ca7a1= 76a6 Block size following
> technological growth] - by Pieter Wuille
>
> [https://lightning.network/lightning-netwo= rk-paper.pdf The Bitcoin Lightning
> Network: Scalable Off-Chain Instant Payments] - by Joseph Poon & T= haddeus
> Dryja
>
> =3D=3DDeployment=3D=3D
>
> If consensus is achieved, deployment can be made at a future block num= ber at
> which difficulty will change.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>

--089e0122aaeee92291051e4c5970--