Well, if it's not going to be height, I think median time of the previous block is better than the time of the current one, and would also solve Chun Wang's concerns. But as said I prefer to use heights that correspond to diff recalculation (because that's the window that bip9 will use for the later 95% confirmation anyway). On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgar...@gmail.com> wrote:
> From a code standpoint, based off height is easy. > > My first internal version triggered on block 406,800 (~May 5), and each > block increased by 20 bytes thereafter. > > It was changed to time, because time was the standard used in years past > for other changes; MTP flag day is more stable than block height. > > It is preferred to have a single flag trigger (height or time), rather > than the more complex trigger-on-time, increment-on-height, but any > combination of those will work. > > Easy to change code back to height-based... > > > > On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I agree that nHeight is the simplest option and is my preference. >> Another option is to use the median time from the previous block (thus >> you know whether or not the next block should start the miner confirmation >> or not). In fact, if we're going to use bip9 for 95% miner upgrade >> confirmation, it would be nice to always pick a difficulty retarget block >> (ie block.nHeight % DifficultyAdjustmentInterval == 0). >> Actually I would always have an initial height in bip9, for softforks too. >> I would also 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 (that way even SPV nodes will notice when a softfork or hardfork >> happens and also be able to tell which one is it). >> I should update bip99 with all this. And if the 2 mb bump is >> uncontroversial, maybe I can add that to the timewarp fix and th recovery >> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to >> follow bip99's recommendations and doesn't want to give 6 full months as >> the pre activation grace period). >> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> In many BIPs we have seen, include the latest BIP202, it is the block >>> time that determine the max block size. From from pool's point of >>> view, it cannot issue a job with a fixed ntime due to the existence of >>> ntime roll. It is hard to issue a job with the max block size unknown. >>> For developers, it is also easier to implement if max block size is a >>> function of block height instead of time. Block height is also much >>> more simple and elegant than time. >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
