Using the subVer field as a user-agent equivalent

[Mike Hearn]

This is just a heads up that yesterday I checked code into BitCoinJ that sets the subVer in its version message to "BitCoinJ 0.1.99".

The subVer field is a string field in the version message. The official client just sets it to the empty string, and it's only used as a filter on the (never used so far) broadcast alerts.

For people who are implementing the BitCoin protocol, let's use this field as an HTTP User-Agent equivalent.

[1714010787]

1714010787

[1714010787]

1714010787

[theymos]

Sounds good. Can you give an example hex dump of such a message so I know what the byte ordering looks like? Is it the same as the command?

[Mike Hearn]

It's UTF-8 encoded first character first.

It's not the same as the command string. That is a NULL or length terminated character array. This is regular string encoding, so varint + characters.

[jgarzik]

The subVer field is a string field in the version message. The official client just sets it to the empty string, and it's only used as a filter on the (never used so far) broadcast alerts.

This is incorrect.  The client has used this in the past.

To get the history behind a single line of code, use "git blame $file"  You can see the official client made full use of this field in a790fa46f40d751307f86c37a709eb119768ce5b, and presumably older clients exist that use this field.

[Mike Hearn]

I see that it was set to ".8" but that only seemed to be used in printing out the version number. I didn't see uses of it elsewhere, did I miss one?

[jgarzik]

I see that it was set to ".8" but that only seemed to be used in printing out the version number. I didn't see uses of it elsewhere, did I miss one?

That's the purpose of the field.  Whenever we have a four-dotted release 0.3.20.1, we set pszSubVer.  It is part of the overall program version.  It is separate AFAICT because satoshi needed an extra field, and the dotted-triple 0.3.20 is already part of a fixed encoding scheme that sets converts X.Y.Z to a single integer number.

Presumably you're aware of the network protocol so presumably you can see how it is not feasible to add a fourth qualifier to the encoded version.

So, I disagree with your change, it stomps on a field bitcoin has used in the past six months.

We can change this if/when the client version becomes separate from the protocol version.  cdecker proposed this in https://github.com/bitcoin/bitcoin/pull/63  His implementation was not desirable, but I think the genesis of the idea was sound.

[Mike Hearn]

Honestly, I think 3 version numbers is quite enough. There's nothing morally wrong with having the first number be higher than zero :-)

Regardless of how it was used in the past six months, the way it's used now is as an arbitrary string that acts as a filter on broadcast messages. That's a useful thing to have. If we did introduce a separate user-agent field, it'd be exactly the same as subVer, which would be odd.

Also, the previous usage of subVer was only used internally. The one sent by a peer has never been used, as far as I can tell, because there's never been an alert broadcast.