Author: Jorge Timón 2015-12-18 20:10:02
Published on: 2015-12-18T20:10:02+00:00
The discussion revolves around determining the max block size in Bitcoin based on either height or time. Jeff Garzik suggests that from a code standpoint, using height is easy and his internal version triggered on block 406,800, increasing by 20 bytes thereafter. However, time was later preferred over height as it was used in years past for other changes; MTP flag day is more stable than block height. Jorge Timón agrees that nHeight is the simplest option but suggests using the median time from the previous block to determine if the next block should start miner confirmation. If bip9 is used for 95% miner upgrade confirmation, Timón proposes always picking a difficulty retarget block. Timón also wants to add an initial height in bip9 for softforks and use the sign bit as the "hardfork bit" that gets activated for the next diff interval after 95% is reached and a hardfork becomes active. Chun Wang suggests that it is easier to implement the max block size as a function of block height instead of time and highlights the difficulty pools face when issuing jobs with unknown max block sizes due to ntime roll.
Updated on: 2023-06-11T02:23:49.967450+00:00