BIP 34 established the rules for updating the block version.
If 75% of the network is producing blocks of version N, then don't accept blocks of version N if they are invalid
If 95% of the network is producing blocks of version N, then don't accept blocks of less than version N (permanent change)
However, this doesn't provide a clear definition of what the new version is. If there were two proposals for version 3 blocks, then 75% (or even 95%) of the network could be using version 3 blocks, but would be incompatible.
What about tweaking the rules for handling block updates.
The network would have a "live" version (L) for blocks. This is currently 2.
- blocks above version L+2 should be rejected
- blocks below version L should be rejected
- blocks of version L + 1 are considered proposed version upgrades but are identical to version L blocks except for the version number
-- The last 32 bytes of the coinbase script contains the hash of the proposed BIP
-- If the preceding byte is 0, this indicates that this is a hard forking update
- If more than 75% of the last 1000 blocks are version L + 1 or L + 2 and have the same BIP hash
-- reject blocks of version L + 2 that don't comply with the BIP
- If more than 95% of the last 1000 blocks are version L + 1 or L + 2 and have the same BIP hash
-- increment the live version by 2 (so reject all blocks below L + 2)
-- The BIP hash doesn't have to be included in subsequent blocks
A message should be added to the network protocol so that BIP text can be obtained once the 95% threshold is reached. A node could ask for the text of any BIP that was accepted by the network.
The client should track headers for the hard fork. When a user connects, the client could compare the total POW to the main chain according to its own rules and the POW for the chain, if it just checks the headers.
If the longest POW chain contains a hard forking update to a block version that the client doesn't support, it could display a message of the form "A hard forking change has been accepted by the miners of the network. A client update is required to continue on what they propose is a better set of rules for the main chain. It is recommended that you only update to a new client version if you agree with the proposed changes. If you do not update, then you will remain on the original, non-forking chain."
