Chun Wang [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-25 📝 Original message:Proposal 1 looks good, but ...
📅 Original date posted:2015-08-25
📝 Original message: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
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Github:
> https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
>
> <pre>
> BIP: 1xx
> Title: Dynamically Controlled Bitcoin Block Size Max Cap
> Author: Upal Chakraborty <bitcoin at upalc.com>
> Status: Draft
> Type: Standards Track
> Created: 2015-08-24
> </pre>
>
> ==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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
📝 Original message: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
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Github:
> https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
>
> <pre>
> BIP: 1xx
> Title: Dynamically Controlled Bitcoin Block Size Max Cap
> Author: Upal Chakraborty <bitcoin at upalc.com>
> Status: Draft
> Type: Standards Track
> Created: 2015-08-24
> </pre>
>
> ==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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>