public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Jannes Faber <jannes.faber@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
Date: Fri, 29 Jan 2016 14:11:52 -0500	[thread overview]
Message-ID: <20160129191152.GA18253@savin.petertodd.org> (raw)
In-Reply-To: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

      parent reply	other threads:[~2016-01-29 19:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29  2:31 [bitcoin-dev] Best (block nr % 2016) for hard fork activation? Jannes Faber
2016-01-29 16:39 ` Gavin Andresen
2016-01-29 18:50   ` Jorge Timón
2016-01-29 19:11 ` Peter Todd [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160129191152.GA18253@savin.petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jannes.faber@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox