Upal Chakraborty [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-27 📝 Original message:Proposal 1 does not deal ...
📅 Original date posted:2015-08-27
📝 Original message: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 at 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
> <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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/a2d51ee3/attachment-0001.html>;
📝 Original message: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 at 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
> <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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/a2d51ee3/attachment-0001.html>;