Author: Jorge Timón 2015-12-18 19:52:19
Published on: 2015-12-18T19:52:19+00:00
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 sign bit can be used as the "hardfork bit" that gets activated for the next diff interval after 95% is reached when a hard fork becomes active. Further, bip99 needs to be updated with all these recommendations while adding the 2 MB bump to the timewarp fix. In another email, Chun Wang via bitcoin-dev raised concerns about how it's harder for pools to issue a job with a fixed ntime due to the existence of ntime roll and how it's easier for developers if the max block size is a function of block height instead of time. They suggest that block height is more simple and elegant than time.
Updated on: 2023-06-11T02:23:40.372798+00:00