From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Hard fork via miner vote
Date: Sat, 20 Jun 2015 18:46:52 +0100 [thread overview]
Message-ID: <CAE-z3OVJbJ=qq3OZvuxWW=17r32aAZf9fRLWd9pHdSw60k7Ftw@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3730 bytes --]
I agree giving notice that the change is going to happen is critical for a
hard fork. If miners vote in favor, they need to give people time to
upgrade (or to decide to reject the fork).
The BIP 100 proposal is that no change will happen until a timestamp is
reached. It isn't clear exactly how it would work.
Testnet: Sep 1st 2015
Mainnet: Jan 11th 2016
It suggests 90% of 12000 blocks (~83 days).
This means that if 10800 of the last 12000 blocks are the updated version,
then the change is considered locked in.
I think having an earlier "fail" threshold would be a good idea too. This
guarantees notice.
Assuming 3 is <old rule> and 4 is <new rule>
If the median of 11 timestamp is after 1st Sep 2015 and less than 10800 of
the last 12000 blocks are version 4+, then reject version 4 blocks
If the median of 11 timestamp is after 1st Nov 2015 and at least 10800 of
the last 12000 blocks are version 4+, then reject version 3 blocks
(lock-in)
If the median of 11 timestamp is after 1st Jan 2016 and at least 10800 of
the last 12000 blocks are version 4+, the allow <new rule>
This means that if the 90% threshold is lost at any time between 1st Sep
and 1st Nov, then the fork is rejected. Otherwise, after the 1st Nov, it
is locked in, but the new rules don't activate until 1st Jan.
For block size, miners could still soft fork back to 1MB after 1st Nov, it
there is a user/merchant revolt (maybe that would be version 5 blocks).
On Sat, Jun 20, 2015 at 6:13 PM, Pieter Wuille <pieter.wuille@gmail•com>
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
>
>
[-- Attachment #2: Type: text/html, Size: 4658 bytes --]
next prev parent reply other threads:[~2015-06-20 17:46 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 [this message]
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='CAE-z3OVJbJ=qq3OZvuxWW=17r32aAZf9fRLWd9pHdSw60k7Ftw@mail.gmail.com' \
--to=tier.nolan@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