> 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.
Could make sense. There would be an alternative to preserve more 1 byte IDs on the cost of a (much) smaller 2 byte ID space: Reserve the short ID 0xFF as an indication for a 2 bytes short ID (additional 256 short IDs with 2 bytes). That could be done later outside BIP324. The 0xFF approach would lead to approx. 207 unused 1 byte short IDs (while Murchs approach would give us approx. 79 unused 1 byte short IDs). The signal bit two byte approach would however lead to ~32k more two byte message IDs. The main (and only?) benefit of short IDs is bandwidth. Short ID 1-12 are reserved for string based IDs and thus, new and rarely sent message types must not always use a short ID. Maybe the BIP should state that only frequent sent messages should reserve a short ID, though, the BIP itself assigns short IDs to all(?) message types (including low frequent messages like SENDHEADERS). Maybe exclude message types that expected to be only sent once from assigning a short ID? /j _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
