[bitcoin-dev] SegWit activation proposal with 2MB Hard Fork by next Block Halving on 2020
*Proposal*: Verify whether 50% Tx mined from SegWit activation block to block 63 are SegWit Tx. If yes, increase legacy max block size to 2MB and SegWit max block size to 8MB. *Implementation*: This proposal either needs to be implemented in next release of Bitcoin Core or require SegWit activation period restart while it is implemented & released. *Rationale*: This proposal minimizes the chance of a chain split, while sticking to the original bitcoin scaling roadmap, i.e. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html Thanks & Regards, Upal Chakraborty ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP 106 : Graphs Required
Hello, First of all, I'm not sure if it is the right place to ask for such help. But, I thought, someone might just help out. I'm looking for two graphs to analyze the effectiveness of BIP 106, which can be found at https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki. Blockchain.info currently provides a graph plotting the historical data of block size for each block, which can be found at... https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address= I need two similar graphs plotting max block size cap against each block, calculated as per my two proposals in BIP 106. Is it possible for anyone to provide these two graphs assuming max block size cap for block 1 was 1mb ? Thanks & Regards, Upal Chakraborty ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
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 <1240...@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]. >
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
Can we please keep this mail chain discussion specific to the proposed draft - https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki ? I understand, voting process is an important subject of discussion. But, that may be discussed in a separate mail chain. On Wed, Aug 26, 2015 at 11:58 AM, Hector Chu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 26 August 2015 at 01:29, Peter Todd via bitcoin-dev > wrote: > > For instance, a very simple toy example that would work is just XORing > your vote with SHA256(the entire blockchain) > > Uh, that would totally not work. > > I think my proposal of using CLTV to lock coins (votes) is better. > Failing a soft-fork to implement that in time, counting votes from the > UTXO set is also ok - the difference between that and CLTV is that it > is not as strong an evidence of commitment. > ___ > 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
[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
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/bitcoi
[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
I have tried to solve the maximum block size debate in two different proposal. i. Depending only on previous block size calculation. ii. Depending on previous block size calculation and previous Tx fee collected by miners. 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 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) ) MaxBlockSize = TotalTxFeeInLastDifficulty * MaxBlockSize / TotalTxFeeInLastButOneDifficulty Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) ) MaxBlockSize = TotalTxFeeInLastDifficulty * MaxBlockSize / TotalTxFeeInLastButOneDifficulty Else Keep the same MaxBlockSize Details: http://upalc.com/maxblocksize.php Requesting for comment. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Regarding... i. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010493.html ii. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010499.html Could we please keep the conversation specific to the proposal presented at http://upalc.com/maxblocksize.php ? If you find any demerits to this, please point them out. Otherwise, I'll ask for a BIP. The proposal in algorithmic format is as follows... 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
I think, keeping the reduction part is necessary to have it demand driven. Otherwise, we could just increase it to a fixed size. If the max cap is high, but there is not enough Tx in the mempool, then after one big block many will go small. This will not be good when block reward become small and mining revenue become dependent on Tx fee. But, if reduction is there, max cap will come down soon and all miners will see revenue from Tx fee again. Proposal details: http://upalc.com/maxblocksize.php On Wed, Aug 19, 2015 at 2:28 AM, Danny Thorpe wrote: > I like the simplicity of this approach. Demand driven response. > > Is there really a need to reduce the max block size at all? It is just a > maximum limit, not a required size for every block. If a seasonal > transaction surge bumps the max block size limit up a notch, what harm is > there in leaving the max block size limit at the "high water mark" > indefinitely, even though periods of decreased transaction volume? > > I'd argue to remove the reduction step, making the max block size > calculation a monotonic increasing function. Cut the complexity in half. > > -Danny > > On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Regarding: >> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html >> >> >> I am arguing with the following statement here... >> >> *I see problems to this approach. The biggest one I see is that a miner >>> with 11% of hash power could sabotage block size increases by only ever >>> mining empty blocks.* >> >> >> >> First, I would like to argue from economics' point of view. If someone >> wants to hold back the block size increase with 11% hash power by mining >> empty blocks, he has to sacrifice Tx fees, which is not economical. 11% >> hash power will most likely be a pool and pool miners will find out soon >> that they are losing Tx fees because of pool owner's intention. Hence, >> they'll switch pool and pool owner will lose out. This is the same reason >> why 51% attack will never happen, even if a pool gets more than 51% hash >> power. >> >> >> Next, I would like to propose a slightly modified technical solution to >> this problem in algorithmic format... >> >> 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 >> >> This is how, those who want to stop increase, need to have more than 50% >> hash power. Those who want to stop decrease, need to have more than 10% >> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In >> this approach, not only miners, but also the end user have their say. >> Because, end users will fill up the mempool, from where miners will take Tx >> to fill up the blocks. Please note that, taking first 2000 of the last 2016 >> blocks is important to avoid data discrepancy among different nodes due to >> orphan blocks. It is assumed that a chain can not be orphaned after having >> 16 confirmation. >> >> Looking for comments. >> >> >> >> >> >> ___ >> 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
[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Regarding: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html I am arguing with the following statement here... *I see problems to this approach. The biggest one I see is that a miner > with 11% of hash power could sabotage block size increases by only ever > mining empty blocks.* First, I would like to argue from economics' point of view. If someone wants to hold back the block size increase with 11% hash power by mining empty blocks, he has to sacrifice Tx fees, which is not economical. 11% hash power will most likely be a pool and pool miners will find out soon that they are losing Tx fees because of pool owner's intention. Hence, they'll switch pool and pool owner will lose out. This is the same reason why 51% attack will never happen, even if a pool gets more than 51% hash power. Next, I would like to propose a slightly modified technical solution to this problem in algorithmic format... 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 This is how, those who want to stop increase, need to have more than 50% hash power. Those who want to stop decrease, need to have more than 10% hash power, but must mine more than 50% of MaxBlockSize in all blocks. In this approach, not only miners, but also the end user have their say. Because, end users will fill up the mempool, from where miners will take Tx to fill up the blocks. Please note that, taking first 2000 of the last 2016 blocks is important to avoid data discrepancy among different nodes due to orphan blocks. It is assumed that a chain can not be orphaned after having 16 confirmation. Looking for comments. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
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
