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

[Fillippone]

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.

[maflcko]

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 rpc/gui: Remove 'Unknown block versions being mined' warning #15471
• Remove 16 bits from versionbits signalling system (BIP320) Remove 16 bits from versionbits signalling system (BIP320) #13972

[iemwill]

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

[laanwj]

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.

[luke-jr]

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]

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]

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]

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]

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]

It has at least three adverse affects:

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

[maflcko]

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.

[sradforth]

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]

@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]

@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]

@rebroad See ASICBoost.

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

Miners do not decide protocol changes.

[iemwill]

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]

@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]

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]

Saw a 70... yesterday

[nelsnelson]

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

[maflcko]

See d82b2c6