Hi Dave

Thanks for the review...

>> ==== Short Command ID ====
>> 
>> To save valuable bandwidth, the v2 message format supports message command
>> short IDs for message types with high frequency. The ID/string mapping is a
>> peer to peer arrangement and MAY be negotiated between the initiating and
>> responding peer.
> 
> Why is this optional and only specified here for some message types
> rather than being required by v2 and specified for all message types?
> There's only 26 different types at present[1], so it seems better to
> simply make this a one-byte fixed-length field than it is to deal with
> variable size, mapping negotiation, per-peer mapping in general, and
> (once the network is fully v2) the dual-logic of being able to process
> messages either from a short ID or a full command name.

One thing I was trying to avoid is some sort of central planing.

Strings as message command identifier do usually bring some sort of collision resistance when competitive implementations work on different features.
An example are the service bits where we AFAIK had an (almost) collision.
This is the main reason why I think we should avoid setting the short IDs mandatory (naturally by not giving all commands a short ID).

Short IDs do probably make most sense for messages with high frequency.
By only giving frequent messages a short ID, we may avoid ID collisions in future.

Short IDs can be altered with the message protocol version (not the transport protocol, the message protocol like 70015, etc.) and new/different negation should be straight forward.

I just ran some random stats (non representative) and inv makes about 66% of all messages (pruned peer, not helping IBDing others) followed by tx and getdata.
Those three probably deserve a short ID.

I have no big objection against adding short IDs for other commands as long as we don’t make short IDs mandatory.
Though, there are little benefits for commands like VERSION, FILTERxx, SENDHEADERS, etc.,... and, we only(?!) have 244 short IDs.

/jonas