Date: Fri, 29 Jan 2016 14:11:52 -0500
From: Peter Todd <pete@petertodd.org>
To: Jannes Faber <jannes.faber@gmail.com>
Message-ID: <20160129191152.GA18253@savin.petertodd.org>
References: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3"
Content-Disposition: inline
In-Reply-To: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
Precedence: list


--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 29, 2016 at 03:31:05AM +0100, Jannes Faber via bitcoin-dev wrot=
e:
> On the other hand when a non-contentious hard fork is rolled out, one cou=
ld
> argue that it's actually best for everyone if the remaining 1% chain
> doesn't stand a chance of ever reaching 2016 blocks anymore (not even by a
> decent sized attacker trying to double spend on stragglers). Also causing
> all alarm bells to go off in the non-updated clients.
>=20
> Have people thought through all the different scenarios yet?

I wrote up some of those risks in my "Soft Forks Are Safer Than Hard
Forks" post the other week:

https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks

I was writing mainly in terms of technical risks for deployment
non-controversial forks; for controversial forks there's many more
failure scenarios. In any case, on technical grounds alone it's obvious
that hard-forks without very high - 95% or so - activation thresholds
are quite dangerous.

In general, it should be remembered that high activation thresholds for
hard-forks can always be soft-forked down after the fact. For instance,
suppose we initially used 100% support over the past one month of blocks
as a hard-fork threshold, but can't get more than 96% support. A
soft-fork with the following rule can be implemented:

    If 95% of the past blocks vote yes, voting against the hard-fork is
    not allowed.

As soft-forks can be rolled out quite quickly, implementing this in the
event that a hard-fork isn't getting sufficient support won't add much
delay to the overall process; as it is a soft-fork, only miners need to
adopt it for it to take effect.

For this reason I'd suggest any hard fork use 99%+ activation
thresholds, measured over multi-week timespan. Hard-forks should not be
controversial for good social/political reasons anyway, so there's
little harm in most cases to at worst delaying the fork by two or three
months if stragglers won't upgrade (in very rare cases like security
issues there may be exceptions; blocksize is certainly not one of those
cases).

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

--r5Pyd7+fXNt84Ff3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQGrBAEBCACVBQJWq7l0XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwN2RmNTNkZGEyODBmMTQxNjhjYTJlYjYzMmIxYjg2YmJh
YmE1ZDkwZjdkMzhiNjAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuzqgf/cuFXN2IT/l12nwrrzwO3KnuX
7MoeLwEhR8X0xIEd2lCrYyRKlFIFVV4F0fVzOl8fhLwBobZiGf0TylBYAHDf8DJN
G1Emn8nOuIqwjEFCpoEk+5niv4CUs5I7p7UVuKvjbRakMMEE358l4RJTaT6pJs7Q
3wXU3B81cUFPpOyVgLp/nksUgeJLLYnfBs6nF6mZZu655Zz15733H1ZPS3FYCMJb
0MputiDHLrGXu3vh67PYb08XtzvrufHI3KqGI9NVXlXCdG0aMkP+Hb4PU52VuN6H
sarBmUO70fRCw/d+WYq4+wr/85qTucSaAPhp+dPZ+x0QnPGLFitPI7hDTFmy5A==
=pNLE
-----END PGP SIGNATURE-----

--r5Pyd7+fXNt84Ff3--