From: Roy Badami <roy@gnomon•org.uk>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Hard fork via miner vote
Date: Sat, 20 Jun 2015 21:07:53 +0100 [thread overview]
Message-ID: <20150620200751.GW13473@giles.gnomon.org.uk> (raw)
In-Reply-To: <20150620184250.GV13473@giles.gnomon.org.uk>
> I just wish that half as much energy had gone into discussing
> whether we want a 100% supermajority or a 99% supermajority or an
> 80% supermajority, as has gone into discussing whether we want 1MB
> blocks or 8MB blocks or 20MB blocks.
And I understand that Gavin is now proposing that a 75% supermajority
should be enough. This constantly reducing threshold worries me
greatly.
There is a risk that we get a situation where a stable amount of
hashing power somewhat over 75% (say 80%) accepts the fork - and
therefore triggers it - but both a significant minority (say 20%) of
hashrate rejects it *and* the economic majority rejects it.
I'm not saying this is a likely outcome - indeed I hope it's not - but
it is a _possible_ outcome. Ok, the chain that the economic marjority
is using will have a bit of a temporary crisis due to 50 minute block
times, but it will recover in a few weeks as difficulty adjusts. And,
in the worst case, you end up with two competing semi-stable
ecosystems both claiming to be 'the real Bitcoin'.
My fear is that in that situation it could take an extended period -
perhaps many months - for one fork to clearly win and the other fork
to lose support (or at least lose sufficient support to be relegated
to altcoin status). I think such an extended period of uncertainty
would be the ultimate worst case scenario for Bitcoin. It _probably_
wouldn't be fatal to Bitcoin, but it would certainly be far worse for
Bitcoin than getting the blocksize wrong even by an order of magnitude
(in either direction). Therefore if we can design the hardfork
mechanism to make such an outcome impossible, I believe we really need
to.
roy
prev parent reply other threads:[~2015-06-20 20:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPg+sBijQ0Q9U00hUaotYujqW8M+v1ED+PV+ap2g7b0Z4=RNSA@mail.gmail.com>
2015-06-20 17:13 ` Pieter Wuille
2015-06-20 17:26 ` David Vorick
2015-06-20 18:11 ` Pieter Wuille
2015-06-20 18:17 ` Matt Whitlock
2015-06-20 17:46 ` Tier Nolan
2015-06-20 18:42 ` Roy Badami
2015-06-20 20:07 ` Roy Badami [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=20150620200751.GW13473@giles.gnomon.org.uk \
--to=roy@gnomon$(echo .)org.uk \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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