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