[Bitcoin-development] Hard fork via miner vote

[Bitcoin-development] Hard fork via miner vote

[Pieter Wuille]

[-- 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 --]

Re: [Bitcoin-development] Hard fork via miner vote

[David Vorick]

[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]

I see it as unreasonable to expect all nodes to upgrade during a hardfork.
If you are intentionally waiting for that to happen, it's possible for an
extreme minority of nodes to hold the rest of the network hostage by simply
refusing to upgrade. However you want nodes to be able to protest until it
is clear that they have lost the battle without being at risk of getting
hardforked out of the network unexpectedly.

I think it makes sense to add a second fuse. After the 95% barrier has been
crossed, a 6 week timer starts that gives the remaining 5% time to upgrade.
If they still don't upgrade, they have intentionally forked themselves from
the network and it is not something that the remaining 95% need to be
concerned with.

On Sat, Jun 20, 2015 at 1: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: 3701 bytes --]

Re: [Bitcoin-development] Hard fork via miner vote

[Tier Nolan]

[-- 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 --]

Re: [Bitcoin-development] Hard fork via miner vote

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On Sat, Jun 20, 2015 at 7:26 PM, David Vorick <david.vorick@gmail.com>
wrote:

> I see it as unreasonable to expect all nodes to upgrade during a hardfork.
> If you are intentionally waiting for that to happen, it's possible for an
> extreme minority of nodes to hold the rest of the network hostage by simply
> refusing to upgrade. However you want nodes to be able to protest until it
> is clear that they have lost the battle without being at risk of getting
> hardforked out of the network unexpectedly.
>

You can't observe the majority of nodes, only miners, and weighed by
hashrate. If you need a mechanism for protest, that should happen before
the hard fork change code is rolled out. I am assuming a completely
uncontroversial change, in order to not confuse this discussion with the
debate about what hard forks should be done.

So I am not talking about protest, just about deploying a change. And yes,
it is unreasonable to expect that every single node will upgrade. But there
is a difference between ignoring old unmaintained nodes that do not
influence anyone's behaviour, and ignoring the nodes that power miners
producing actual blocks. In addition, having no blocks on the old chain is
safer than producing a small number, as you want full nodes that have not
noticed the fork to fail rather than see a slow but otherwise functional
chain.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 1775 bytes --]

Re: [Bitcoin-development] Hard fork via miner vote

[Matt Whitlock]

On Saturday, 20 June 2015, at 8:11 pm, Pieter Wuille wrote:
> you want full nodes that have not noticed the fork to fail rather than see a slow but otherwise functional chain.

Isn't that what the Alert mechanism is for? If these nodes continue running despite an alert telling them they're outdated, then it must be intentional.

Re: [Bitcoin-development] Hard fork via miner vote

[Roy Badami]

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

Re: [Bitcoin-development] Hard fork via miner vote

[Roy Badami]

> 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