The services filed in the version messages shall be used

[piotr_n]

IMHO, each specific functionality of a node (maybe even each message type), should have its own bit in the services field.
I'm talking about the 64-bit field that currently is always set to 1.

Using the "version" filed to indicate whether a node supports things like "getheaders", "ping", "mempool", "reject" or bloom filters - this is a mistake.
Currently you basically get to choose between version 6000x and 7000x, but the reality is never that simple.

For instance: the node I use does not support bloom filters (probably never will), but it does support things like "getheaders" or "ping".
And I wish my node could be honest about which commands it will reply or act upon, and which it won't, but with the current protocol this is just impossible to be honest about it.
All I can tell you is version 60002, 70001 or 70002 - and none of them will actually be correct.

My point is: if the folks developing the core could get advantage of the services field (which shall not be a hassle), I believe the protocol itself (and thus the network as a whole) would have benefited from it.


EDIT:
Also I'd like to point out that the service field (unlike the version filed) is sent along with IP inside the addr message.
So for instance if you have an SVP client, then you could just ignore all the nodes that are not going to serve the bloom filtering for you and never connect to them.

[1715639874]

1715639874

[gweedo]

I agree this is a great idea, this would also help to serve many different functioning clients, and help grow the protocol into many different directions.

I hope Tsar Gavin would approve this!

[TierNolan]

That is a pretty old BIP to support custom services discovery.

https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Service_Discovery

If that was included, there wouldn't need to be quite the same level of "hoarding" of the services bits.

According to the protocol.h file:

// Bits 24-31 are reserved for temporary experiments. Just pick a bit that
// isn't getting used, or one not being used much, and notify the
// bitcoin-development mailing list. Remember that service bits are just
// unauthenticated advertisements, so your code must be robust against
// collisions and other cases where nodes may be advertising a service they
// do not actually support. Other service bits should be allocated via the
// BIP process.

You could pick random bits from 24-41.

If you want "official" recognition, then you could submit a BIP.  The reference implementation would be pretty easy, since it would support all the packets.

An alternative would be for a new message that lists the supported messages.  It wouldn't be quite as good.  Peers would have to connect, ask for the packet, and then disconnect if they don't have it.