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.
Topic: Using the subVer field as a user-agent equivalent (Read 1417 times)
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.
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?
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.
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.
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.
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?
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.
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.
Jump to: