If you truly have a consensus then the rational behavior is to permanently change the nodes behavior after the trigger.
On 06/22/2015 02:21 PM, Gavin Andresen wrote: > On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd <p...@petertodd.org > <mailto:p...@petertodd.org>> wrote: > > > Since it's possible that block timestamps aren't chronological > in order, what would happen if a block following a size increase > trigger is back in the past before the size increase? Would that > block have a lower size restriction again? Would using block > height not be a more stable number to work with? > > In the nVersion bits proposal that I co-authored we solved that > issue by > comparing the timestamp against the median time, which is > guaranteed by > the protocol rules to monotonically advance. > > > That complicates the implementation quite a bit. > > I mostly implemented a variant that replaced the MAX_BLOCK_SIZE > constant with a function that took both a timestamp and a block > height, and there are several places in the current reference > implementation where digging out the block height (or, worse, > calculating the median timestamp for the block) would involve changing > quite a few functions in the call-chain or acquiring the cs_main lock > to consult the current best chain. > > -- > -- > Gavin Andresen > > > _______________________________________________ > 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
