MIME-Version: 1.0
In-Reply-To: <20150622205420.GA8892@savin.petertodd.org>
References: <dd09d1e5-57fb-46ef-8bc0-0fdccf9e7abb@me.com>
	<20150622205420.GA8892@savin.petertodd.org>
Date: Mon, 22 Jun 2015 17:21:40 -0400
Message-ID: <CABsx9T2FxNEEUx7_ZRf2NpQk1fdqMKtfzccX-duBjOn-ksS0cg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c3c842135f3b051921dca5
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Precedence: list

--001a11c3c842135f3b051921dca5
Content-Type: text/plain; charset=UTF-8

On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd <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

--001a11c3c842135f3b051921dca5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jun 22, 2015 at 4:54 PM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=
=3D"h5">&gt; Since it&#39;s possible that block timestamps aren&#39;t chron=
ological in order, what would happen if a block following a size increase t=
rigger 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 stab=
le number to work with?<br>
<br>
</div></div>In the nVersion bits proposal that I co-authored we solved that=
 issue by<br>
comparing the timestamp against the median time, which is guaranteed by<br>
the protocol rules to monotonically advance.<br></blockquote><div><br></div=
><div>That complicates the implementation quite a bit.</div><div><br></div>=
<div>I mostly implemented a variant that replaced the MAX_BLOCK_SIZE consta=
nt with a function that took both a timestamp and a block height, and there=
 are several places in the current reference implementation where digging o=
ut the block height (or, worse, calculating the median timestamp for the bl=
ock) would involve changing quite a few functions in the call-chain or acqu=
iring the cs_main lock to consult the current best chain.</div></div><div><=
br></div>-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></di=
v>
</div></div>

--001a11c3c842135f3b051921dca5--