Differentiate Protocol version from client version #63
Conversation
|
I understand the motivation, but this seems contrary to satoshi's original intent. Recommend deferring this for a year or three :) |
|
And what would the motivation be? It would allow others to be compatible with the mainline client, without having to create a new version each time the mainline is updated, just to ensure compatibility? It won't be the last change conflicting with Satoshi's original intents. |
|
I second cdecker's question - what is satoshi's original intent? Is his intent that there shall be One True Client? |
|
Satoshi was clearly brilliant, but that doesn't mean we have to follow his original intent religiously. I think this is a good idea, especially as we move towards more clients in more languages, on more devices. |
|
I agree with the intent -- differentiate client & proto version -- but not the implementation in this pull request. And in general, the current protocol does permit some flag-based extensibility beyond simple protocol versioning. We could simply freeze the as-exported proto version, and add flags where necessary to indicate new feature[set]s. |
|
Can you elaborate on the flags? I don't think I've come across the code you're talking about. |
|
Just to respond to the criticism on the patch. I myself found it strange to ask for a patch for a thing that isn't solvable with a patch, but I was asked to do it. It is not difficult to add protocol extensibility, as discussed on the Forum, it just needs either a new message (capabilities?) or an extension to the version message (variable list of strings each denoting capability support). But it's not the goal of this pull request. This one is just to say "please, please don't increment the proto version with each client release", if that point comes through I don't care what happens to this pull request. |
|
The "nServices" bitmask is sent with each version message, at the beginning of each TCP connection between two P2P nodes. |
|
True, I had forgotten about the nServices bitmask, my bad. I have a few criticisms about that too, but I'll create a new Forum thread for them, since this is only to decouple protocol versioning from client versioning. Estensibility should be left for a broader discussion. |
|
The two issues are coupled, as I indicated in my original reply. |
|
Ok, I think we aren't thinking about the same kind of extensibility. My goal basically is to have a minimal protocol that is standardized (let's say the current protocol), it is simple and easy to understand. The protocol version should indicate that if a client supports the protocol version it'll understand the messages that are going to be sent. Where up until now the protocol version was being incremented every time a new version of the client was released, and you'd have to reverse engineer all changes (if any) from the main client. Extensibility doesn't really come into play at this point (not as I think of it anyway). Extensibility is another dimension where, while maintaining the basic protocol as is to avoid forcing others to upgrade, additional functionality can be built on top. I just want to make sure that alternative clients don't have to release a dummy update each time the main client updates just to say "yeah, well nothing changed in the protocol, we still support it". Changes to the protocol need to be explicit, rare and publicly announced. Most changes can be implemented by adding simple extensions, without breaking compatibility with alternative clients. |
|
Anyway, to get back on track with this pull request: jgarzik, if I understand you correctly you agree with my point, right? Keeping the protocol version distinct from the client version allows us to differentiate the implementations and thus grow and secure the network. I don't care if this pull request makes it into the main trunk, as long as we alternative developers get a commitment from the main client developers that they won't increment the version number if no protocol changes have been made (or even better if breaking changes are reduced to a bare minimum). |
|
Alternative clients, nor mainline clients, have -never- had to release a dummy update, due to the current release scheme. That's a red herring, and an invalid justification. The network protocol has always been backwards compatible, even way back to ancient client versions. I understand the desire to separate the two versions, but beyond that point you're making up nonsensical justifications for problems that don't exist. |
|
Sorry you feel that way. I see that there is no point in continuing this conversation, consider the pull request withdrawn. Although I maintain that my points are still valid. You were the one who brought up extensibility, whereas I maintain that protocol evolution is different than protocol extension. The need to separate protocol development from client development is felt by many of us, and if I got that point through, it is a huge victory. |
|
To use an absurd example, it is trivial to see how we can create a flag "use a totally different protocol." There is no limit to extensibility through flags. We could simply freeze currently reported protocol version, while still incrementing client version. |
|
I don't know if it is still possible to merge this but this is ridiculous that this has not been merged. As a developer for an alternative client I don't want to depend solely when the mainline add GUI features and calls that an update. "Add flags"? I assume you meant software versioning flags and not the services flags. That will only hold for so long, I mean, you will end up with 0.3.12.32.1z and no-one will be happy. Can't we just call this the X version of the protocol and when the protocol actually changes, up the number by one and document the changes in the wiki? If you did mean the services flags those should be carefully considered before introducing, once introduced they will stay forever. They are not at all made for marking "new" or "different" clients but network capabilities. Also, the use of (or lack of) the subversioning field is also irritating, why not simply have the name + version of the client? The packet will get a bit bigger yes, but that doesn't seem to bother anybody with all the 64-bit values. It's very handy to see what software versions are currently running in the network. Please, reconsider to merge this a step towards client diversity - please do not treat the protocol as the same thing as the client or we will never have a stable protocol nor developers that want to keep up with an every so changing protocol number. |
|
I would like to see this issue addressed. As someone starting another Bitcoin client it concerns me greatly that the core Bitcoin client is trying to monopolise what should be decentralised currency. How are we supposed to differentiate between protocol version and client? A client shouldn't be the protocol and forcing it to be the same thing is a silly coupling. blueCommand also makes a good point for the health of the network. Knowing the client composition is important. |
|
As original author of the issue it is in my interest to have it adressed, but I have to correct a small misunderstanding: the flags are a good way to identify capabilities as jgarzik pointed out. It is a bitfield in the version message which allows boolean announcements about the capabilities of the client. |
|
+1 |
Renamed total_tokens to num_tokens to make it more appropriate for TX51
Encoding and transaction creation overhaul and tests
simple test for algos
…reate_sendto-contract Added automated tests for ITDS
Added createrawtext RPC command
As discussed in Issue #5 the protocol version should be differentiated from the client version.
It makes live so much easier for alternative implementations.