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

From: Ross Nicoll <jrn@jrn.me.uk>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Date: Mon, 22 Jun 2015 22:32:15 +0100	[thread overview]
Message-ID: <55887EDF.3070505@jrn.me.uk> (raw)
In-Reply-To: <CABHVRKQoHERWSLwF-885jis9PqV07qYEJrScxwxfePwv0C9EoQ@mail.gmail.com>

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

Potentially daft question, why not use a minimum height? Yes, it's 
imprecise, but over an extended period of time they're good enough IMHO.

I'd have to do more careful calculations to confirm, but block 388,000 
should be about right as a minimum.

Ross

On 22/06/2015 22:04, Stephen Morse wrote:
>
>     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.
>
>
> I'm also a fan of using the median time to ensure that there is a 
> clear point where the protocol change starts. Something like "blocks 
> only allow the larger block size if the associate pindex has 
> pindex->GetMedianTimePast() after midnight 11 Jan 2016 and where a 
> supermajority showing support for the fork has previously been reached".
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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