Date: Mon, 22 Jun 2015 16:54:21 -0400
From: Peter Todd <pete@petertodd.org>
To: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
Message-ID: <20150622205420.GA8892@savin.petertodd.org>
References: <dd09d1e5-57fb-46ef-8bc0-0fdccf9e7abb@me.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB"
Content-Disposition: inline
In-Reply-To: <dd09d1e5-57fb-46ef-8bc0-0fdccf9e7abb@me.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Precedence: list


--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 22, 2015 at 07:32:22PM +0000, Jean-Paul Kogelman wrote:
>=20
>=20
> On Jun 22, 2015, at 11:18 AM, Gavin Andresen <gavinandresen@gmail.com> wr=
ote:
>=20
> The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00=
:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 second=
s (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestam=
p 2083190400). The maximum size of blocks in between doublings will increas=
e linearly based on the block's timestamp. The maximum size of blocks after=
 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
> =A0
> 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 t=
he past before the size increase? Would that block have a lower size restri=
ction again? Would using block height not be a more stable number to work w=
ith?

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.

--=20
'peter'[:-1]@petertodd.org
0000000000000000138b2613c026e0ed1dbf6f8f193f1c3115bdf540dc22fbf6

--tThc/1wpZn/ma/RB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJViHX4XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMzhiMjYxM2MwMjZlMGVkMWRiZjZmOGYxOTNmMWMzMTE1
YmRmNTQwZGMyMmZiZjYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvbHggAksxGsQfw/1AfNS+6pXBnbN1F
shxxH7cZ44H9eozwmcUxrZp4n2MEZcCXpxewVvF19Hl/w+zzp6Vps0x0g93L4QUF
OdNhJLG9lueX2OoH1QHEE0BaRd52E7IxQ2x06c6mHwpNiFdPWZDipgy9Z1THHuDr
04Uey+Zwl7p7kyCl6DG5QpMxUJIWzwcpOmi7S0erz3jvpow7Ig2mqehKlOz0Dwk/
JLPjxnSzb7lnm1R54j48hF8s507TWFWLXKCmPfKZTNXa92ps63+apcAl7ocq0pBH
1TUKV+Ns1fv81yKr1y0RjrbwnjfdP4iu1dzGKVYwDLmjTAdC55big4Q9WEuKDg==
=pX9a
-----END PGP SIGNATURE-----

--tThc/1wpZn/ma/RB--