Questions about version number in block header

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: polaker on January 27, 2020, 05:09:56 PM

Does this mean that version number actually is not part of the consensus rule, since miners could set whatever version number they want?

There are consensus rules regarding what the version number can be. But there is no consensus rule saying that the version number must be a particular value.

E.g. there is a rule saying that the number cannot be less than 3. But there is no rule saying that it must be 4, so it can be 4, 5, or any other number so long as it is greater than 3.

polaker

newbie

Activity: 8

Merit: 3

Quote from: achow101 on January 27, 2020, 02:01:33 PM

Quote from: polaker on January 27, 2020, 12:45:36 PM

1) I noticed that the version number could be different for blocks. How could we introduce a new version number by soft forking?

A soft fork isn't required to use a different version number. Some numbers cannot be used, but, for the most part, miners can set whatever block version number they want. This is what allows them to use the version number to signal soft fork readiness and also allows them (unfortunately) to use asicboost.

Does this mean that version number actually is not part of the consensus rule, since miners could set whatever version number they want?

gmaxwell

staff

Activity: 4326

Merit: 8951

Consensus rules set how things are hashed not how they're communicated.

If you wanted to store or communicate (to compatible software) headers using a compact int you're free to do so... but it would be a mostly pointless savings (two byte? meh. and even then only if you weren't representing current common numbers which have higher bits set, or using an alternative compact int format).

The size of them going into a hash is pretty irrelevant, because unless you reduce the compression function run count the hash takes essentially the same time.

The bytes of prev which are forced to be zero because of this block's difficulty are a much more sensible thing to save, particularly because as difficultly increases the amount of nonce you need increases proportionally... so it would have been logical to use the zeros for additional nonce and to have made the separate nonce field just 8-bits. With that and updating time to be current no one would need extranonce.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: polaker on January 27, 2020, 12:45:36 PM

1) I noticed that the version number could be different for blocks. How could we introduce a new version number by soft forking?

A soft fork isn't required to use a different version number. Some numbers cannot be used, but, for the most part, miners can set whatever block version number they want. This is what allows them to use the version number to signal soft fork readiness and also allows them (unfortunately) to use asicboost.

Quote from: polaker on January 27, 2020, 12:45:36 PM

2) Why doesn't it use compact Int to save bytes?

Compact int isn't very compact. There is not much space to be saved there, and really no reason for the version to be a super expandable field.

polaker

newbie

Activity: 8

Merit: 3

I got these questions while reading the protocol doc.

1) I noticed that the version number could be different for blocks. How could we introduce a new version number by soft forking?

2) Why doesn't it use compact Int to save bytes?

Topic: Questions about version number in block header (Read 160 times)