Author: Erik 2015-11-14 15:25:19
Published on: 2015-11-14T15:25:19+00:00
In a recent message, a Bitcoin developer named Erik shared his thoughts on BIP proposals concerning the maximum block size. He believes that if BIP101 is fully utilized, it will eventually centralize Bitcoin as it will outperform consumer hardware. Hence, he proposes a different solution to the problem. He has not discussed two BIP103s, as both are proposing linear and exponential growth, respectively. The all-linear growth option will not work in the future because the growth will be too slow soon or later. The exponential growth assumes that the technology will rise in a certain growth, which may be too slow or too fast according to the technical evolution. None of these proposals will actually handle an unexpected future case.Erik proposes a formula for block size increase that is not complicated. The 2^(1/2...) formula creates a number in the interval 1 to 2. The formula can tell if the block max size every second year shall double or be the same based on the last 6 months of votes. Because Erik believes there should always be an increase to secure a stable growth of the network, there is also a linear formula that the growth cannot be lower than. If the 2^(1/2...) formula gives a lower increase than the linear value for the next retarget, then the linear value should be used instead. One of the benefits of using an exponential formula is that it could easily be fit for any arbitrary block period by changing the divisor.BIP105 has another feature not mentioned in Erik's proposal that is to place a vote requires a cost as a difficulty increase. However, Erik thinks this is not a good option since it will make users refrain from voting to "earn" a difficulty lowering. The votes are the only soft way Erik sees to let the blockchain know if it should allow growing faster or slower. He also doesn't see a benefit of having the opportunity to lower the block max size in comparison to the risks involved with that. Then it proposes a limit to how much it can increase at all which will need a new hard fork when we need to increase the limits of the proposal.Erik thinks that John Sacco's BIP proposal is not similar to his one since there is no voting mechanism to make the increase dynamic. Also, John proposes that the size will double at each halving instead of each difficulty retarget. This could, in contrast, increase the fees by making larger spaces in the blocks, decrease the fees because of that the fee required to enter the next block will be lowered. Also, it proposes a hard limit at 32 MB which, again, needs a new hard fork later.The formula Erik proposed is not very different in complexity from the difficulty retarget formula and will still need the last recalculated value to be computed. One of the benefits of using an exponential formula is that it could easily be fit for any arbitrary block period by changing the divisor. The two-week interval will be smooth enough. In conclusion, Erik thinks that if the 2^(1/2) block size limit actually works, it would not cause rounding errors in different implementations, and the next size should be calculated on that value.
Updated on: 2023-06-11T01:09:21.267329+00:00