From: Pieter Wuille <pieter.wuille@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] Hard fork via miner vote
Date: Sat, 20 Jun 2015 19:13:06 +0200 [thread overview]
Message-ID: <CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBijQ0Q9U00hUaotYujqW8M+v1ED+PV+ap2g7b0Z4=RNSA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2013 bytes --]
next parent reply other threads:[~2015-06-20 17:13 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 [this message]
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
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='CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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