Author: Tier Nolan 2015-06-20 17:46:52
Published on: 2015-06-20T17:46:52+00:00
Pieter Wuille, a Bitcoin developer, has expressed his concern over the use of block version voting as a trigger mechanism for hard forks, stating that it is a bad idea and can lead to confusion among non-miner nodes. He suggests using a timestamp switch-over or adding a block voting threshold as a means to keep humans in the loop, but if used, a 100% threshold should be employed. The BIP 100 proposal calls for no change to occur until a timestamp is reached, although it is unclear how this would work. The proposal also suggests a 90% threshold of the last 12,000 blocks being updated before the change is considered locked in. To guarantee notice of the change, an earlier 'fail' threshold is suggested; if the median of 11 timestamps is after September 1st, 2015 and less than 10,800 of the last 12,000 blocks are version 4+, then reject version 4 blocks. If the median of 11 timestamps is after November 1st, 2015 and at least 10,800 of the last 12,000 blocks are version 4+, then reject version 3 blocks (lock-in). If the median of 11 timestamps is after January 1st, 2016 and at least 10,800 of the last 12,000 blocks are version 4+, then allow. If the 90% threshold is lost at any time between September 1st and November 1st, the fork is rejected. Otherwise, after November 1st, it is locked in, but the new rules do not activate until January 1st. For block size, miners could still soft fork back to 1MB after November 1st, should there be a user/merchant revolt.
Updated on: 2023-06-10T00:04:56.104142+00:00