Topic: Best method of changing the maximum block size - page 2. (Read 1620 times)
20% only when 2016 blocks are over 80% full. That cannot be gamed by anyone.
That seems like just an invitation for someone to game it.
How much percent of the hashing power would it take to just drive block size up forever using that formula?
(20% per step! Srsly? At least the 1% in original post would take 100 difficulty periods (or so; is it closer to 70 really?) to double it but compound interest is a bitch, ask investors whether 1% per difficulty interest on an investment would be legit or a ponzi...)
-MarkM-
How much percent of the hashing power would it take to just drive block size up forever using that formula?
(20% per step! Srsly? At least the 1% in original post would take 100 difficulty periods (or so; is it closer to 70 really?) to double it but compound interest is a bitch, ask investors whether 1% per difficulty interest on an investment would be legit or a ponzi...)
-MarkM-
This is not a criticism of the voting strategy above or any adaptive strategy for changing the maximum block size, just an interim solution if there is no consensus and time is drifting on.
This simple solution does the minimum necessary to preserve the status quo until a permanent strategy is implemented.
It is suggested that in the next version of bitcoin-qt and bitcoind the 1Mb block size limit constant becomes a variable that increases by 20% if the average block within the previous difficulty period is >80% of the max size limit.
The importance of an interim solution is that as many nodes as possible can be upgraded at the convenience of their owners. This drastically reduces the odds of forking the bitcoin blockchain with many users "on each side" which may well result if there was an emergency change required after a sharp growth in transaction volumes causing 1Mb block saturation.
This simple solution does the minimum necessary to preserve the status quo until a permanent strategy is implemented.
It is suggested that in the next version of bitcoin-qt and bitcoind the 1Mb block size limit constant becomes a variable that increases by 20% if the average block within the previous difficulty period is >80% of the max size limit.
The importance of an interim solution is that as many nodes as possible can be upgraded at the convenience of their owners. This drastically reduces the odds of forking the bitcoin blockchain with many users "on each side" which may well result if there was an emergency change required after a sharp growth in transaction volumes causing 1Mb block saturation.
After hearing everything, I believe this is so far the best method proposed:
I don't like any of my other proposals for the reason I don't think any of them can accurately take into account all of the complex variables that determine if the block size should increase. The increased bandwidth requirements of a larger block size should weigh into the decision of whether or not to increase it, which is something that Gavin's proposal does. But it happens in a fragile way that requires measurements and doesn't come to a rapid consensus.
The voting method is the simplest and most robust way for increasing the block size, because it lets individual miners choose whatever method they want for making the decision. Some may decide that bandwidth matters. Others may want simply to limit the total scarcity. Voting is a proxy for deferring the implementation of the "decision function" for raising the block size to later. It gives us a flexible system that requires most of the mining community to agree, without tying us down to a specific formula like doubling the size periodically or requiring difficult to agree on measurements.
The optimum method for increasing the block size would have to factor in the exchange rate, people's tolerance for fees, and the effects of the increased bandwidth requirement. I do not believe this can be modeled in an automated fashion. Therefore, we solve the problem in parallel by letting miners try to solve this complex equation for their own use-case and vote on the result.
The 90% and 1% figures are just examples, other values may work better (but once they are published they can never change).
I'm not sure whether or not I am in favor of even increasing the block size. There is definitely a strong argument to be made for just leaving it alone. However, if we do decide to increase the block size I think this is the best method so far. I would love to hear counter examples or criticisms.
1) A boolean flag is added to each block. The flag represents the block solver's yes or no vote for increasing the block size. The independent miner or mining pool sets this flag according to their preference for an increase.
2) Every time the difficulty is adjusted, the number of yes votes is counted from the last adjustment. If the number of yes votes is greater than 90%, then the block size is increased by 1%. Both percentages are baked-in constants, requiring a hard fork to change.
2) Every time the difficulty is adjusted, the number of yes votes is counted from the last adjustment. If the number of yes votes is greater than 90%, then the block size is increased by 1%. Both percentages are baked-in constants, requiring a hard fork to change.
I don't like any of my other proposals for the reason I don't think any of them can accurately take into account all of the complex variables that determine if the block size should increase. The increased bandwidth requirements of a larger block size should weigh into the decision of whether or not to increase it, which is something that Gavin's proposal does. But it happens in a fragile way that requires measurements and doesn't come to a rapid consensus.
The voting method is the simplest and most robust way for increasing the block size, because it lets individual miners choose whatever method they want for making the decision. Some may decide that bandwidth matters. Others may want simply to limit the total scarcity. Voting is a proxy for deferring the implementation of the "decision function" for raising the block size to later. It gives us a flexible system that requires most of the mining community to agree, without tying us down to a specific formula like doubling the size periodically or requiring difficult to agree on measurements.
The optimum method for increasing the block size would have to factor in the exchange rate, people's tolerance for fees, and the effects of the increased bandwidth requirement. I do not believe this can be modeled in an automated fashion. Therefore, we solve the problem in parallel by letting miners try to solve this complex equation for their own use-case and vote on the result.
The 90% and 1% figures are just examples, other values may work better (but once they are published they can never change).
I'm not sure whether or not I am in favor of even increasing the block size. There is definitely a strong argument to be made for just leaving it alone. However, if we do decide to increase the block size I think this is the best method so far. I would love to hear counter examples or criticisms.
Jump to: