warning='45 of last 100 blocks have unexpected version'

Fillippone commented at 6:02 am on July 5, 2019: none

Hello everyone: I am running: { “version”: 180000, “protocolversion”: 70015, “walletversion”: 169900,

In the debug log I get: 2019-07-05T05:47:37Z UpdateTip: new best=00000000000000000006a8e968937ed0d26cba95af48aec9a35030dae34068ea height=583923 version=0x20000000 log2_work=90.811056 tx=431748422 date=‘2019-07-05T05:47:31Z’ progress=1.000000 cache=67.4MiB(597483txo) warning=‘43 of last 100 blocks have unexpected version

As I am running version 0.18, I would have expected this kind of message go away, as the message “unknown version"was deactivated in the latest release. What is the difference between “unexpected version” and “unknown version”? Why one warning has been suppressed with latest release and the other is still present (and quite common as I can see?) This different approach on very similar errors is generating user confusion. Thank you.

MarcoFalke commented at 8:48 pm on July 8, 2019: member

Bitcoin Core does not expect that miners are setting those versions, which is why it is logged.

See also

rpc/gui: Remove ‘Unknown block versions being mined’ warning #15471
Remove 16 bits from versionbits signalling system (BIP320) #13972

MarcoFalke closed this on Jul 8, 2019

iemwill commented at 8:22 pm on November 3, 2019: none

Maybe warning is a bit too hard in that case and it could be renamed to info or something similiar…

laanwj commented at 10:51 am on November 4, 2019: member

I tend to agree it’s useless information at this point, I’d venture removing it completely, or only showing it if some logging debug flag is enabled.

Usually we follow the principle that we don’t want to have any things in the log by default that might worry users unnecessarily.

MarcoFalke reopened this on Nov 4, 2019

luke-jr commented at 5:32 pm on November 4, 2019: member

Miners are essentially disregarding the protocol rules and stuffing bogus information into the version field without any sort of community consensus.

Perhaps the right solution is a softfork to make these bits invalid.

iemwill commented at 7:04 pm on November 4, 2019: none

Miners are essentially disregarding the protocol rules and stuffing bogus information into the version field without any sort of community consensus.

Does not sound good…

laanwj commented at 12:26 pm on November 6, 2019: member

Miners are essentially disregarding the protocol rules and stuffing bogus information into the version field without any sort of community consensus.

That’s absolutely true, but also I think, not really something that most users need to be bothered with constantly.

luke-jr commented at 4:23 pm on November 6, 2019: member

It is necessary for users to safeguard the protocol against malicious miners. Without the ability to enforce this as a protocol rule, the best we can do is warn. Without even a warning, users can’t do their job of protecting the protocol at all.

laanwj commented at 4:27 pm on November 6, 2019: member

I don’t think it’s a matter of black and white, yes, ‘stealing’ version bits for ASICboost was a absolutely controversial, at the time. On the other hand, it’s well known and documented now. It has no adverse effect on the network. The only thing it does, concretely, is cause these warnings.

luke-jr commented at 4:48 pm on November 6, 2019: member

It has at least three adverse affects:

Indicating the miner does not respect that the protocol is user-defined.
Economically forcing would-be honest miners to also violate the protocol to remain cost-effective.
Transforming SHA2 from an ASIC-friendly PoW algorithm to an ASIC-complex algorithm, increasing the barrier to entry for new manufacturers.

MarcoFalke commented at 1:06 am on April 27, 2020: member

The feature request didn’t seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest. Pull requests with improvements are always welcome.

MarcoFalke closed this on Apr 27, 2020

sradforth commented at 7:12 am on September 5, 2020: none

The client needs to decide if this is worthy of notifying the user about and cluttering the log page.
Bitcoin is an interesting project in that it’s as much political as technical, the miners have found a way to use these bits for signalling which doesn’t compromise the security yet clearly find this version bit setting useful otherwise they wouldn’t do it.

Seems clear these warnings should be merely verbose log items most people never need to see because these warnings are now so common practice they are never going to disappear.

i.e. If the client isn’t going to start rejecting the blocks (which let’s face it, would be insane to hardfork over) this warning is unnecessarily concerning new users of bitcoin.

As a suggestion, perhaps we could just say “69 of last 100 blocks contain miner signalling flags”, relegate it to the verbose mode and we update the logging system to reflect how it’s actually being used?

practicalswift commented at 8:47 am on September 5, 2020: contributor

@sradforth I feel your pain! Thanks for sharing your experience. You might want to leave a comment (or perhaps “Concept ACK”) in the open issue #19603 (Show the "<n> of the last 100 blocks have unexpected version" warning only when running -debug=validation?) if you want this addressed. Hopefully this will get addressed soon if enough end-users voice their concern.

rebroad commented at 8:52 pm on February 23, 2021: contributor

@luke-jr “Transforming SHA2 from an ASIC-friendly PoW algorithm to an ASIC-complex algorithm” - can you provide a source for this please?

I would say for this issue, as it’s less than 50, it’s a non issue, and that consensus is not reached for a protocol change, and Core should not adapt to the malpractice, whereas if it was over 50, then the miners have spoken, and Core perhaps should adapt to the new consensus.

luke-jr commented at 9:35 pm on February 23, 2021: member

@rebroad See ASICBoost.

then the miners have spoken, and Core perhaps should adapt to the new consensus.

Miners do not decide protocol changes.

iemwill commented at 1:10 pm on February 24, 2021: none

Maybe warning is a bit too hard in that case and it could be renamed to info or something similiar…

From my current point of view it was a warning and should be one again, if changed.

Maybe also a reopening?

sylvandb commented at 6:20 am on March 11, 2021: none

@rebroad See ASICBoost.

then the miners have spoken, and Core perhaps should adapt to the new consensus.

Miners do not decide protocol changes.

Of course they do. Consensus is the foundation of the network and miners are the only consensus that matters. Nobody else can enforce the protocol if the miners do not cooperate. If a majority of miners decide they are going to change the protocol, it’s changed. If enough miners disagree with the change then we have a fork. The only question that remains is which (or if) one of the forks will die.

The one thing that prevents miners from taking over the network thus far is self-interest. Meaning, thus far it has been judged to be more profitable to let Core set the rules, more or less. That balance may change. For example, perhaps miners will decide “no more halving” and so maintain block rewards while causing a permanent inflation.

iemwill commented at 6:45 am on March 11, 2021: none

Consensus is the foundation of the network and miners are the only consensus that matters.

I agree with the first sentence.

Miners are the first part of consensus, the “chain-robustness” will be given by the validation of every participating node.

Otherwise the chain/token-connection makes no sense in the law of satoshis paper.

iemwill commented at 5:02 pm on June 15, 2021: none

Saw a 70… yesterday

nelsnelson commented at 3:21 pm on May 16, 2022: none

=1.000000 cache=79.6MiB(675325txo) warning='97 of last 100 blocks have unexpected version'

MarcoFalke commented at 3:28 pm on May 16, 2022: member

See https://github.com/bitcoin/bitcoin/commit/d82b2c6e65ff1ade508e2e8abeb07d0ff37e09c4

DrahtBot locked this on May 16, 2023

warning=‘45 of last 100 blocks have unexpected version’ #16343