Topic: Standardising block versions (Read 675 times)

The only way to do that is to 51% attack bitcoin itself. We are talking about soft-fork changes, right?

I can see your point and I admit this is the downside of my protocol, having said that, the protocol itself can be upgraded at any point by the same method.


Currently if we upgraded blocks to version 3 and made some change that causes the 0.9.1 client to reject them, my client won't warn me that I am using an incorrect version. Instead it will carry on regardless and false chain attacks can be made.

I am a firm believer that protocols should be made to be as unambiguous as possible. The idea of having a block version field which is valid as long as it is not 0 or 1 seems rather stupid to me. In future instead of a nice structure we will have a . This may be a rather cosmetic point but at the moment (correct me if I am wrong) there are no unit tests to test if alternative bitcoin implementations accept blocks with versions greater than 2 and if a programmer were to miss that small detail it could open up the opportunity to fork the network.


I can't see how changes can be non sequential without causing the network to fork. The one problem with my protocol is if there are two opposing changes proposed at the same time, nobody would know which change the new odd block version numbers represents.

We already haved used the block numbers for upgrades, but nodes need to have new code for the upgrade, that new code implements the switch rule. Different changes have different reasonable switch criteria. Defining it in advance would constrain behavior without any advantage that I can see.

Your suggestion also presupposes a single sequential line of changes. Version X comes after version Y strictly and monotonically. This seems unlikely to be possible to ensure without a heavy amount of centralization.

What do you mean by exclusive? Exclusive to what?

Not all possible version upgrades are exclusive. You could have a version 3 block which adds an optionally validated field (version 3 blocks have it while version 2 blocks do not).

Any thoughts at all on this? It could be used to implement BIP 62 changes.

There isn't anything in the bitcoin code which stops miners producing blocks with a block version of greater than 2. (2 is the current block version)

Currently this doesn't produce any issues, but if the block version is upgraded at some point and there are already version 3 blocks in the chain then future clients will have to have special rules for parsing them.

Implementing a change to reject blocks with a version greater than 2 would allow forks to be created so it isn't an option unless a majority of nodes have upgraded.

I suggest the following change to the code:

Implement a rule such that from some block far in the future the following rules will apply:
- Even block version numbers represent blocks which have a change to the protocol
- Odd block version numbers signal that a change to the protocol is about to happen and that nodes should update their software. The blocks are no different to the ones which have appeared before.
- Even block versions are valid if either 950 of the last 1000 blocks have a version which is one less or any block with the same version has been accepted into the chain and no blocks with a version of two more have been accepted into the block chain.
- Odd blocks versions are valid if the last block has a version which is one less or any block with the same version has been accepted into the chain and no blocks with a version of one more have been accepted into the block chain.

What does this mean?

This means that an update to the bitcoin protocol can only happen smoothly with 95% miner agreement.

Users are warned when a protocol change is about to happen and their software does not have the necessary updates. It should give users about a weeks notice.

Legacy software which has not upgraded after a protocol change knows that it does not have the required updates to verify the blockchain so will fail gracefully.

I welcome your feedback on this proposal, please ask questions if you wish me to clarify anything.