This is intended to supercede pull request #932, for the following minor reasons:

1. removes the actual protocol version increment. IMO this should be external to the 'pong message' commit.

and under the principle of making code self-documenting...

2. use a named constant rather than a magic number for version behavior switching. bitcoin code is too full of magic numbers, and we should resist adding more.
3. place that constant in sipa's newly minted version.h, as a central location for future version-related constants like this.

Independent, yes, but where is a better place for version information than version.{h,cpp}?

It is an odd policy that the "version" module excludes certain classes of version information and not others. That seems to violate the Principle of Least Surprise.

Agree, but calling them both "_VERSION" will be very confusing.

No more confusing than the existing PROTOCOL_VERSION vs. CLIENT_VERSION, each with the _VERSION suffix (which I argue is not confusing at all, but rather a logical naming scheme for each).

If it appeals to one's sense of symmetry, we can move PROTOCOL_VERSION to version.* as well.

IMO, version.h should contain version information for the current client, that will change over time.

I agree that feature-specific thresholds that will be "written in stone forever" should go somewhere else. Maybe there will eventually be enough for a bip_versions.h :-) (if we tracked down other magic version numbers we could already do so)

Another suggestion would be to rename it to BIP0031_MIN_VERSION to it clear that it is a version threshold (though the comment explains this as well of course...).

No, we don't need multiple version.* modules in the tree.

To me, mixing the client version (metadata about the project you're compiling) and the network version (a property of the protocol being implemented) in the same module is wrong. It's like having a source file in firefox that encdes both information about the firefox browser version and the differences between HTML4 and HTML5.

The fact that both are called version and have a similar number scheme is an historic artifact, and I would prefer to get them separated rather sooner than later. Maybe remove the moniker '_VERSION' from all protocol-related code, and simply call it "protocol 60000". I agree that we need nice constants for magic protocol switches, but they do not belong in version.h. Really.

This is being WAY overthought.

1. It is silly to have multiple version modules, for that will create confusion among outside reviewers.
2. It is silly to put version constants outside the existing version module, for humans outside the dev team will naturally look for anything version-related in a module called "version."
3. It is even more silly to rename a protocol version constant to something other than "VERSION". It -is- a version number.

It is not a historical accident that the protocol version is called "PROTOCOL_VERSION". The naming precisely describes its purpose, and changing that name would be detrimental to understanding by outside reviewers.

It is just bonkers to remove the "_VERSION" word from all version-related constants in bitcoin unrelated to client version. That is creating more problems than it is solving.

You can use the exact same argument that this causes confusion for "outside
reviewers". Do we need to increase the BIP0031_VERSION with a new release?
How is it different from the CLIENT and PROTOCOL version?... etc.

Helpfully, there is a comment for outside reviewers in the code I added, solving this imagined problem.

Certainly, a comment saying "This relates to the protocol version being used in P2P connections, and is independent from the client version" is enough to make it acceptable (I see no such comment right now, though...). Still, such constants belong in the networking code, imho.

Updated to add such comments, and further illustrate the usage.

Other magic protocol version constants:

• protocol.h: 31402 (nTime in CAddress)
• main.cpp: 31402 (avoid requesting addresses from older nodes)
• main.cpp: 32000...32400 (don't ask for blocks from these versions)

added, along with 209

Meh, ACK.

Reminder to bump our own PROTOCOL_VERSION to 60001 too...

@luke-jr yes, that will come in a separate cover