Date: Wed, 16 Nov 2016 16:01:00 -0500
From: Peter Todd <pete@petertodd.org>
To: Alex Morcos <morcos@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20161116210100.GC5639@savin.petertodd.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
	<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
	<CADJgMzunxU2-7Z_ZPafNY4BPRu0x9oeh6v2dg0nUYqxJbXeGYA@mail.gmail.com>
	<33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org>
	<CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
	<A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
	<CAE-z3OXdiyS_5HEFu1VLG1DH_K1QUBTSy49nXh1M4tcuoi6D_w@mail.gmail.com>
	<CAPWm=eUQjpELFB2A9vJ8j6Y5Zvts9YqkZYNCO0aDnNSb+VwFvg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="O3RTKUHj+75w1tg5"
Content-Disposition: inline
In-Reply-To: <CAPWm=eUQjpELFB2A9vJ8j6Y5Zvts9YqkZYNCO0aDnNSb+VwFvg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
Precedence: list


--O3RTKUHj+75w1tg5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wrote:
> I think we are misunderstanding the effect of this change.
> It's still "OK" for a 50k re-org to happen.
> We're just saying that if it does, we will now have potentially introduced
> a hard fork between new client and old clients if the reorg contains
> earlier signaling for the most recent ISM soft fork and then blocks which
> do not conform to that soft fork before the block height encoded activati=
on.
>=20
> I think the argument is this doesn't substantially add to the confusion or
> usability of the system as its likely that old software won't even handle
> 50k block reorgs cleanly anyway and there will clearly have to be human
> coordination at the time of the event.  In the unlikely event that the new
> chain does cause such a hard fork, that coordination can result in everyo=
ne
> upgrading to software that supports the new rules anyway.
>=20
> So no, I don't think we should add a checkpoint.  I think we should all
> just agree to a hard fork that only has a very very slim chance of any
> practical effect.

So, conceptually, another way to deal with this is to hardcode a blockhash
where we allow blocks in a chain ending with that blockhash to _not_ follow
BIP65, up until that blockhash, and any blockchain without that blockhash m=
ust
respect BIP65 for all blocks in the chain.

This is a softfork: we've only added rules that made otherwise valid chains
invalid, and at the same time we are still accepting large reorgs (albeit u=
nder
stricter rules than before).

I'd suggest we call this a exemption hash - we've exempted a particular
blockchains from a soft-forked rule that we would otherwise enforce.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--O3RTKUHj+75w1tg5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQEcBAEBCgAGBQJYLMkJAAoJECSBQD2l8JH7Q3oH/Roi+0I8kT8S2GITOgS+XQRv
Ro8ghB3KrHE76Q4SLM+GT4CZvYevBdcsqM8epeGsOaeLYxpPPhhd0XJJ9+O4/qJo
6+OIbgkWV98IK9ss+uqxYwYam6Z3EJL6WE+Y/sgyfnQkNkHrOObg1e2JeAl4Q31/
/Ty128nR8doRIVU9fh/pnqaP//CrDtogf6mnfVAcRUZZRSXhAGDW8cmXV/xGtXFN
KVszxqkV+8bNxP9zt+oS7Y7hp6m7KpjY8DPQSNCfGop0lVvik9JzmkJGlAKM84+w
zi/oGTO/JiwoaoIbKdVobqMmedKKrP5pIcI6fE03lL0qTKSfdzxk2U32PbNF+aQ=
=ocKT
-----END PGP SIGNATURE-----

--O3RTKUHj+75w1tg5--