Blocks with unexpected version

Francis GASCHET

New Member
Mar 12, 2017
18
17
Dreux (France)
Hello,

I recently migrated the full node I run for 2 years to BU v1.0.1.0-55d8cbd and recently started a second BU node with a better bandwidth.
Now I've this record in debug.log :
2017-03-13 09:54:06 UpdateTip: 37 of last 100 blocks have unexpected version. One example: 0x20000002
It looks coming only from "UpdateTip" as before I got :
2017-03-13 08:21:56 Acceptable block: ver:20000002 time:1489393301 size: 998196 Tx:652 Sig:1033
and even :
2017-03-13 09:11:09 Acceptable block: ver:30000000 time:1489396418 size: 934470 Tx:2224 Sig:3602
A remainder of Bitcoin Core ?

Francis
 
  • Like
Reactions: freetrader

Roy Badami

Active Member
Dec 27, 2015
140
203
These are both valid BIP9 nVersion values. BIP9 redefines the nVersion field to be a bit field rather than a number. To signify BIP9, the most significant bits are 001 (meaning the most significant hex digit is 2 or 3) and the remaining bits indicate 'votes' for specific softfork proposals.

0x20000002 is a vote for segwit
0x30000000 also looks like a BIP9 vote for something - but I don't know what.
 
  • Like
Reactions: Francis GASCHET

Roy Badami

Active Member
Dec 27, 2015
140
203
Incidentally, the benefit of BIP9 (also known as versionbits) is that since it's a bitfield miners can vote for one or none or several ongoing softfork activations by setting the bits for the appropriate proposals. The previous mechanism of BIP34-style activation (also known as IsSuperMajority after the name of the function that implemented it) tacitly assumed a very linear development model, with an incrementing version number in which each new version of block would build on the previous set of changes.

Although this probably wasn't Core's primary motivation, this is actually very valuable for decentralised development. If the community got behind some new softfork proposal today (perhaps something simple and non-contentious that could activate very quickly) then with BIP9 it is possible to signal for activation of this alone; with BIP34-style activation any miner who signalled for this new change would also implicitly be signalling for any other pre-existing ongoing softfork 'vote' (i.e. at present, segwit).
 
Last edited: