Proposed alternatives to the 20MB step function



Summary:

The author of this email argues that raising the block size without a feedback mechanism would be dangerous and foolhardy. There are risks associated with infrastructure scaling, centralization pressures, and delaying the necessary development of a constraint-based fee economy. The author proposes a dynamic block size limit controller, where for each block, the miner is allowed to select a different difficulty (nBits) within a certain range, and this miner-selected difficulty is used for the proof of work check. The default maximum block size limit is then adjusted at regular intervals, and there would be limits on how quickly the block size limit can be adjusted in any one period. This creates an incentive environment where raising the block size has a real cost associated with it: a more difficult hashcash target for the same subsidy reward. The author also points out the limitations of relying on miners to make decisions about issues that develop, as they may not have full domain knowledge or an objective perspective. Therefore, a feedback mechanism is needed to prevent perverse mining incentives, and the allowable miner-selected adjustment to difficulty would have to be tightly constrained. The proposed system allows block size to increase only within the confines of a self-supporting fee economy, providing an emergency relief valve that we can be assured will only be used at significant cost. The author mentions that there have been various discussions on the bitcointalk forums about dynamically adjusting block size limits, and suggests that the true origin of the idea is unclear. The email concludes with the author expressing support for other ideas, such as determining the hard block size limit by a vote of the miners or as a function of block-chain length, but opposing Mike Hearn's proposed jump to 20 MB.


Updated on: 2023-06-09T20:09:42.172095+00:00