Hi Pieter, hello list,

On 26.10.22 12:39, Pieter Wuille via bitcoin-dev wrote:
> 1. The most straightforward solution is using the BIP process as-is: let BIP324
>     introduce a fixed initial table, and future BIPs which introduce new
>     messages can introduce new mapping entries for it. In theory, this is no
>     worse than the current coordination difficulty about command strings, but
>     in practice the risk of collisions due to competing proposals is of course
>     significantly larger with 1-byte IDs vs. 12-byte strings.

 From what I understand we'll have about 35 message types on the network 
with the addition of BIP324. 256 possible IDs sounds like plenty room to 
grow, but perhaps we can be a bit more conservative:

We could use the first bit to signal a 2-byte message ID. That allows us 
to express 128 IDs with 1 byte, but if we need more, we get a total of 
2^15 IDs across 2 bytes.

I would not be too concerned about collisions. Firstly, message types 
would probably be announced to the mailing list as part of the 
corresponding BIP, secondly, any overlooked collision should become 
apparent at implementation time. The risk could perhaps be further 
mitigated by encouraging less prevalent message types to use a 2-byte ID.

Cheers,
Murch