Published on: 2015-12-19T18:20:38+00:00
Chun Wang, a bitcoin developer, has raised concerns over the use of block time to determine the maximum block size in many Bitcoin Improvement Proposals (BIPs), including the latest BIP202. He argues that it is difficult for mining pools to issue a job with the maximum block size unknown due to the existence of ntime roll and suggests that block height would be a simpler and more elegant solution.Peter Todd, another bitcoin developer, responds by proposing that size be calculated from the median time past, which is fixed for a given block and has no dependency on the block header's nTime field.Jeff Garzik, a developer of Bitcoin, suggested a proposal for Bitcoin block size increase. He prefers height activation and one step per block (also height). Under this scheme, the size of the step-per-block increase could be decreased every 210,000 blocks at the time of reward halvings.On December 18, 2015, Jorge Timón via bitcoin-dev proposed two options to improve the Bitcoin network's block time. One option is to use nHeight while the other is to utilize the median time from the previous block.In the discussion thread, several developers are debating over the best method to determine the maximum block size in Bitcoin. One developer suggests using height activation and one step per block, while another argues for median time of the previous block. The original developer expresses interest in hearing from others about possible attacks with different approaches before diverging from the default community approach of switch-based-on-time.The discussion revolves around determining the max block size based on block height or time. Jeff Garzik prefers height activation with one step per block as it is more simple and attacks would occur around the already-heavily-watched flag day activation event, which is useful. However, he wants to hear from others about possible attacks before diverging from the default community approach of switch-based-on-time. Jorge Timón thinks median time of the previous block is better than the time of the current one and would also solve Chun Wang's concerns. He prefers heights that correspond to diff recalculation. From a code standpoint, based off height is easy. The internal version triggered on block 406,800 and each block increased by 20 bytes thereafter. It was changed to time as MTP flag day is more stable than block height.In the discussion thread, several developers are debating over the best method to determine the maximum block size in Bitcoin. One developer suggests using height activation and one step per block, while another argues for median time of the previous block.The Bitcoin community discussed the best way to trigger changes in block size limits. The initial version triggered on block height but was later changed to time, as it was believed to be more stable. There is a preference for a single flag trigger (height or time), however any combination of those will work.The discussion revolves around the simplicity of using nHeight as the preferred option for determining the max block size. Another option suggested is to use median time from the previous block which helps in knowing whether the next block should start miner confirmation or not. It is suggested that it would be nice to always pick a difficulty retarget block, and an initial height should be there in bip9 for softforks too.The latest Bitcoin Improvement Proposals (BIPs), such as BIP202, have established that the maximum block size is determined by the block time. However, from a pool's perspective, it is difficult to issue a job with a fixed ntime due to the existence of ntime roll. This makes it challenging to determine the maximum block size for issuing a job. Developers find it much simpler and more elegant to implement a function of block height instead of time for determining the maximum block size. Block height is considered a better alternative because it is easier to work with and more straightforward than time. In conclusion, while BIPs have set a precedent for the maximum block size being based on block time, there are challenges in implementing this rule for pools and developers. The use of block height is seen as a more efficient and logical alternative.
Updated on: 2023-08-01T17:12:28.704891+00:00