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 19:42:51 +0100 [thread overview]
Message-ID: <20150620184250.GV13473@giles.gnomon.org.uk> (raw)
In-Reply-To: <CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com>
As I've observed before, Gavin originally advocated either a 99% or
100% buy in by miners for a hard fork to trigger.
https://gist.github.com/gavinandresen/2355445
I don't understand why people (Gavin included) now seem to favour a
much more modest supermajority except perhaps that they believe that
that level of consensus is unachievable.
FWIW I'm in favour of a block size increase. 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. (So thank you, Pieter, for raising this.)
roy
On Sat, Jun 20, 2015 at 07:13:06PM +0200, Pieter Wuille wrote:
> Hello all,
>
> I've seen ideas around hard fork proposals that involve a block version
> vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
> believe this is a bad idea, independent of what the hard fork itself is.
>
> Ultimately, the purpose of a hard fork is asking the whole community to
> change their full nodes to new code. The purpose of the trigger mechanism
> is to establish when that has happened.
>
> Using a 95% threshold, implies the fork can happen when at least 5% of
> miners have not upgraded, which implies some full nodes have not (as miners
> are nodes), and in addition, means the old chain can keep growing too,
> confusing old non-miner nodes as well.
>
> Ideally, the fork should be scheduled when one is certain nodes will have
> upgraded, and the risk for a fork will be gone. If everyone has upgraded,
> no vote is necessary, and if nodes have not, it remains risky to fork them
> off.
>
> I understand that, in order to keep humans in the loop, you want an
> observable trigger mechanism, and a hashrate vote is an easy way to do
> this. But at least, use a minimum timestamp you believe to be reasonable
> for upgrade, and a 100% threshold afterwards. Anything else guarantees that
> your forking change happens *knowingly* before the risk is gone.
>
> You may argue that miners would be asked to - and have it in their best
> interest - to not actually make blocks that violate the changed rule before
> they are reasonably sure that everyone has upgraded. That is possible, but
> it does not gain you anything over just using a 100% threshold, as how
> would they be reasonably sure everyone has upgraded, while blocks creater
> by non-upgraded miners are still being created?
>
> TL;DR: use a timestamp switchover for a hard fork, or add a block voting
> threshold as a means to keep humans in the loop, but if you do, use 100% as
> threshold.
>
> --
> Pieter
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
next prev parent reply other threads:[~2015-06-20 18:43 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 [this message]
2015-06-20 20:07 ` Roy Badami
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=20150620184250.GV13473@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