public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: shaolinfry <shaolinfry@protonmail.ch>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Date: Tue, 28 Feb 2017 21:20:29 +0000	[thread overview]
Message-ID: <201702282120.29614.luke@dashjr.org> (raw)
In-Reply-To: <jo5-7HCZX7tgdMpIQgK85HCPP14FWxvOIbjV_oerIfc-HOP1GbK3SxFX82Ls23yU1L7y95QsFFggddMNdo5Sxy7YhTJhRFN1f8d6PaA8b7s=@protonmail.ch>

Without at least a majority hashrate validating blocks, it is possible just a 
single invalid block could split the chain such that the majority continue 
building a most-work on that invalid block.

This failure to validate a softfork is similar in some respects to a hardfork, 
but with one critical difference: the default behaviour of old nodes will be 
to follow the chain with the most-work that was valid under the pre-softfork 
rules. This actually *inverts* the benefit of the softfork over a hardfork, 
and makes a softfork deployed in such a manner de facto behave as if it had 
been a hardfork, IF someone ever mines a single malicious block.

For this reason, I think a minority-hashrate softfork requires a much higher 
degree of social support than merely the widespread agreement typical of 
softforks. It might perhaps require less than the full ~100% consensus 
hardforks require, but it likely comes somewhat close.

Once it gets over 50% hashrate enforcement, however, the situation improves a 
lot more: a malicious block may split obsolete miners off the valid chain, but 
it will eventually resolve on its own given enough time. Due to natural 
fluctuations in block finding, however, automatic measurement may need to look 
for >75%.

So I would suggest that instead of a simple flag day activation, this proposal 
would be improved by changing the flag day to merely reduce the hashrate 
requirement from 95% to 75%.

(In addition to the above concerns, if >50% of miners are hostile to the 
network, we likely have other problems.)

Luke


  parent reply	other threads:[~2017-02-28 21:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-25 23:55 [bitcoin-dev] Moving towards user activated soft fork activation shaolinfry
2017-02-26 17:34 ` Jameson Lopp
2017-02-27 16:02   ` shaolinfry
2017-02-27 16:50     ` Eric Voskuil
2017-02-28 21:20 ` Luke Dashjr [this message]
2017-03-12 15:47 ` shaolinfry
2017-03-05 14:33 Chris Belcher
2017-03-05 18:10 ` David Vorick
2017-03-05 18:48   ` Eric Voskuil
2017-03-05 21:31   ` Nick ODell
2017-03-06  9:18     ` David Vorick
2017-03-06 10:29       ` Edmund Edgar
2017-03-06 23:23         ` Gareth Williams
2017-03-07  1:07           ` Edmund Edgar
2017-03-07 17:37             ` Eric Voskuil
2017-03-07  9:17           ` Tom Zander
2017-03-07 18:13             ` Eric Voskuil
2017-03-07 19:13             ` Alphonse Pace

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=201702282120.29614.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=shaolinfry@protonmail.ch \
    /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