[bitcoin-dev] Best (block nr % 2016) for hard fork activation?

[Peter Todd]

On Fri, Jan 29, 2016 at 03:31:05AM +0100, Jannes Faber via bitcoin-dev wrote:
> On the other hand when a non-contentious hard fork is rolled out, one could
> 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.
> 
> 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).

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000005822b77a904129795a3ff4167c57ed1044f5a93512c830f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160129/14717ba2/attachment.sig>