Topic: Updating block version (Read 859 times)
Unfortunately, "emergency" is pretty incompatible with "informed consent" and "public debate"
Alerting people is what the alert system is for - not to mention the media.
That is a centralized solution.
Any emergency hard-fork will involve centralization; a big part of why hard-forks are so strongly discouraged is the centralization they imply; bitcoin still has never experienced a hardfork.
Alerting people is what the alert system is for - not to mention the media.
That is a centralized solution.
Alerting people is what the alert system is for - not to mention the media.
I don't consider blockchain "voting" for a hard-fork to be especially sane.
It wasn't a vote. The point was that it would notify owners of old clients that a hard fork had happened.
This could also be achieved by having a field in the header. Maybe the LSB of the block version could be used. This would mean incrementing by 2 for each new version. 2 -> 2 -> 2 -> 3 -> 4 -> 4 -> 4 would mean that the update to version 4 was a hard fork. This would mean that versions would have to be even. The version 3 block would have the hash of the rule change. A few of the LSBs of the version could be designated as flags.
It needs to handle, hard and soft forks and also voting vs "emergency" changes.
The notice could be something like
A Hard Fork occurred at block number
The new network rules are incompatible with the old rules.
This is flagged as an EMERGENCY hard fork.
You are NOT required to update to the new rules.
It is recommended that you verify that you agree with the rule change before updating your client.
Your client has been placed in safe mode. New transaction confirmation has been disabled.
You must either update your client to a version compatible with the new rules or manually cancel safe mode.
If you cancel safe mode, then your client will refuse to follow the fork and remain on the original chain.
I don't consider blockchain "voting" for a hard-fork to be especially sane.
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."
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."
Jump to: