Rules being proposed for the 2MB hard-fork bump of Bitcoin Classic:
- Threshold vote by miners, using block.version bit 0x10000000
- Votes after expiration date (timestamp in block header > 2018-01-01 00:00:00 GMT) do not count
- New rule (bigger blocks) not allowed until after threshold reached plus grace period (4 weeks)
- Once threshold reached, voting bit does not matter (but version must be greater than 4 to be compatible with previous soft forks)
Edge case tests missing from current Classic regression test:
Threshold-triggering vote at or just-after the expiration date (two test cases).
Bit-recycling test: if 50 of last 100 blocks have bit 0x10000000 set after the vote expiration time, the 'version obsolete' warning should be triggered (but it should not trigger before then).
REFERENCE:
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
Several differences with the BIP9 proposal:
- Different activation threshold (BIP9 is 95%)
- Activation evaluated at every block, not every retarget interval (easy consensus code change, but non-trivial changes to regression/unit test code)
- Voting expiration defined using median-time-previous instead of block.nTime (easy consensus code change, non-trivial changes to regression/unit tests to create chains with median-times-past exactly at the right time)
- Grace period of four weeks instead of 2016 blocks (again, easy consensus code change, non-trivial changes to regression/unit tests)
- BIP9 proposes the version bit become available for another soft-fork immediately after grace period (would require more regression/unit tests to be written)
Compatibility with code that follows BIP9:
The "version bit becomes available immediately after" rule will require a special case to prevent spurious warnings, assuming the 2MB vote succeeds.
Otherwise, compatibility will be good.