Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Patrick Strateman <patrick.strateman@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

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 <pete@petertodd.org
> <mailto:pete@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


[-- Attachment #2: Type: text/html, Size: 3205 bytes --]