I agree giving notice that t= he change is going to happen is critical for a hard fork.=C2=A0 If miners v= ote in favor, they need to give people time to upgrade (or to decide to rej= ect the fork).

The BIP 100 proposal is that no change wil= l happen until a timestamp is reached.=C2=A0 It isn't clear exactly how= it would work.

Testnet: Sep 1st 2015

Mainnet: Jan 11= th 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.=C2= =A0 This guarantees notice.

Assuming 3 is <old rule>= ; and 4 is <new rule>

If the median of 11 timestamp is after 1= st Sep 2015 and less than 10800=20 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 1= 0800 of the last 12000 blocks are version 4+, then reject version 3 blocks= =C2=A0 (lock-in)

If the median of 11 timestamp is after 1st J= an 2016 and at least 10800 of the last 12000 blocks are version 4+, the all= ow <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.= =C2=A0 Otherwise, after the 1st Nov, it is locked in, but the new rules don= 't activate until 1st Jan.

For block size, miners cou= ld still soft fork back to 1MB after 1st Nov, it there is a user/merchant r= evolt (maybe that would be version 5 blocks).

On Sat, Jun 20, 2015 a= t 6:13 PM, Pieter Wuille <pieter.wuille@gmail.com> wro= te:

Hel= lo 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 its= elf is.

Ultimately, the purpose of a hard fork is asking the whole c= ommunity 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 l= east 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 growi= ng too, confusing old non-miner nodes as well.

Ideally, the fork should be scheduled when one is certain no= des will have upgraded, and the risk for a fork will be gone. If everyone h= as 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 reasonabl= e for upgrade, and a 100% threshold afterwards. Anything else guarantees th= at 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 p= ossible, 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/= listinfo/bitcoin-development

--001a1135ad283de7220518f6a074--