Topic: BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap - page 4. (Read 9415 times)
I have got some very good arguements in the bitcoin-dev list and hence updated the main article. If you have any counter-arguement to this proposal, feel free to put it here or in the comment section of the article - http://upalc.com/maxblocksize.php
Dynamic resizing is the obvious compromise between the camps. Everyone can get what they claim to want from it, without having to compromise either.
If the market chooses bigger blocks, then the market can test whether or not that works out in practice. If yes, then Gavin's design solution actually was the best idea after all. If not, then the market retreating will cause the blocksize to retreat also (which wouldn't be possible under BIP100).
The market could even try out bigger blocks, decide it doesn't work, try the alternative, dislike that more than bigger blocks, and then revert to some compromoise blocksize. Y'know, it's almost as if the free market works better than central planning...
If the market chooses bigger blocks, then the market can test whether or not that works out in practice. If yes, then Gavin's design solution actually was the best idea after all. If not, then the market retreating will cause the blocksize to retreat also (which wouldn't be possible under BIP100).
The market could even try out bigger blocks, decide it doesn't work, try the alternative, dislike that more than bigger blocks, and then revert to some compromoise blocksize. Y'know, it's almost as if the free market works better than central planning...
No sure if you have gone through OP's proposal. BIP 101 has no provision to decrease block size, instead it flat out increases without considering the network status. BIP 100 is employing some miner's voting system, which requires a separate activity from miner's end. The reason I feel OP's proposal is beautiful is because it requires users to fill up nodes with high Tx volumes and then miners to fill up blocks from mempool. So, it is not only the miner, but also the end users have a say in increasing or decreasing block size.
Ah, I did actually mean BIP 101 and not 100. Thanks for pointing it out. And I agree that this proposal sounds good, but I was making the more general point that some form of dynamic resizing scheme is best.
Dynamic resizing is the obvious compromise between the camps. Everyone can get what they claim to want from it, without having to compromise either.
If the market chooses bigger blocks, then the market can test whether or not that works out in practice. If yes, then Gavin's design solution actually was the best idea after all. If not, then the market retreating will cause the blocksize to retreat also (which wouldn't be possible under BIP100).
The market could even try out bigger blocks, decide it doesn't work, try the alternative, dislike that more than bigger blocks, and then revert to some compromoise blocksize. Y'know, it's almost as if the free market works better than central planning...
If the market chooses bigger blocks, then the market can test whether or not that works out in practice. If yes, then Gavin's design solution actually was the best idea after all. If not, then the market retreating will cause the blocksize to retreat also (which wouldn't be possible under BIP100).
The market could even try out bigger blocks, decide it doesn't work, try the alternative, dislike that more than bigger blocks, and then revert to some compromoise blocksize. Y'know, it's almost as if the free market works better than central planning...
No sure if you have gone through OP's proposal. BIP 101 has no provision to decrease block size, instead it flat out increases without considering the network status. BIP 100 is employing some miner's voting system, which requires a separate activity from miner's end. The reason I feel OP's proposal is beautiful is because it requires users to fill up nodes with high Tx volumes and then miners to fill up blocks from mempool. So, it is not only the miner, but also the end users have a say in increasing or decreasing block size.
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
Proposal in bitcoin-dev mailing list - http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html
Requesting for comment - http://upalc.com/maxblocksize.php
Proposal in bitcoin-dev mailing list - http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html
I like your proposal. I've never been against the increase in the block size but always believed, and still do, that it should be more dynamic in nature and follow on actual bitcoin usage instead of it being based on how we think/perceive bitcoin to be used in future.
If it's not dynamic in nature we are bound to run into problems again in future if we say for example double up on the block size only to find out that mass adoption is not happening at the rate we expected. With your proposed solution both sides are covered as the block size will dynamically increase and or decrease based on actual usage. If properly implemented it could mean that we can lay the arguments around block sizes to rest and never need to worry about it becoming an issue again in a couple of years time.
So roughly every two weeks the blocksize halves, doubles or stays the same depending on the traffic that's going on. It's certainly an idea I could get behind as a second preference or fallback if people are absolutely determined to torpedo BIP101. It makes a fair trade-off. And to be clear, I could support such a proposal whether it was introduced in core, or an independent client. I still don't understand this fixation the community has with "trusted" developers. If the effects of the code are obvious and neutral, I don't particularly care who coded it or what their personal views are, or if any other developers disagree for whatever their personal views are. I want an open network that supports the masses if or when they come. I hope this silences all the critics who think people who support larger blocks aren't willing to compromise, because they will if they're presented with a coherent and well-presented alternative like this one.
However, I'm sure if this particular proposal did become the prevailing favourite, the same usual suspects trying to discredit BIP101 would be doing the same for this, calling it an "altcoin", saying upal wants to be a "dictator" and seize control, pretending it's only consensus when they personally agree with it and all the other cheap shots they're taking at BIP101. It'll be interesting to see how this plays out.
However, I'm sure if this particular proposal did become the prevailing favourite, the same usual suspects trying to discredit BIP101 would be doing the same for this, calling it an "altcoin", saying upal wants to be a "dictator" and seize control, pretending it's only consensus when they personally agree with it and all the other cheap shots they're taking at BIP101. It'll be interesting to see how this plays out.
Dynamic resizing is the obvious compromise between the camps. Everyone can get what they claim to want from it, without having to compromise either.
If the market chooses bigger blocks, then the market can test whether or not that works out in practice. If yes, then Gavin's design solution actually was the best idea after all. If not, then the market retreating will cause the blocksize to retreat also (which wouldn't be possible under BIP100).
The market could even try out bigger blocks, decide it doesn't work, try the alternative, dislike that more than bigger blocks, and then revert to some compromoise blocksize. Y'know, it's almost as if the free market works better than central planning...
If the market chooses bigger blocks, then the market can test whether or not that works out in practice. If yes, then Gavin's design solution actually was the best idea after all. If not, then the market retreating will cause the blocksize to retreat also (which wouldn't be possible under BIP100).
The market could even try out bigger blocks, decide it doesn't work, try the alternative, dislike that more than bigger blocks, and then revert to some compromoise blocksize. Y'know, it's almost as if the free market works better than central planning...
This is one of the best proposal I have seen in recent times to solve the max block size problem. I hope, it does not get overlooked by the core & XT devs, because this could potentially stop the divide of bitcoin core & XT.
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.
BIP 106: https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki
Proposal in bitcoin-dev mailing list - http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html
Proposal 1: Depending only on previous block size calculation
The basic idea in alogorithmic format is as follows...
Proposal 2: Depending on previous block size calculation and previous Tx fee collected by miners
The basic idea in alogorithmic format is as follows...
Details: http://upalc.com/maxblocksize.php
Requesting for comment.
i. Depending only on previous block size calculation.
ii. Depending on previous block size calculation and previous Tx fee collected by miners.
BIP 106: https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki
Proposal in bitcoin-dev mailing list - http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html
Proposal 1: Depending only on previous block size calculation
The basic idea in alogorithmic format is as follows...
Code:
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
The basic idea in alogorithmic format is as follows...
Code:
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
Details: http://upalc.com/maxblocksize.php
Requesting for comment.
Jump to: