Refreshed BIP324

Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows. This would provide more space for message IDs and simplify the allocation process. The conversation also addresses the need for negotiation and coordination mechanisms for assigning message IDs, as well as the potential impact on bandwidth and implementation complexity.In order to increase space while maintaining conservatism, suggestions are made to treat the first bit as a 2-byte message ID or use an explicit signaling system. The group agrees to exclude rarely-sent commands from assigning short IDs. There is a discussion on introducing novel 1-byte messages before allocating them and reserving a byte for one-shot messages is discouraged. The mapping table between 1 byte IDs and commands is discussed, with three possible solutions presented: introducing a fixed initial table using the BIP process, maintaining a purely local and hardcoded internal mapping, or negotiating the mapping dynamically without a fixed table.The network is expected to have 35 message types with around 256 possible IDs. To increase conservatism, the first bit could be used to signal a 2-byte message ID or the short ID 0xFF could be reserved. The main benefit of short IDs is bandwidth optimization, but not all message types need to use them. It is suggested that only frequently sent messages should reserve a short ID or exclude one-time message types from assigning a short ID.Pieter Wuille proposes using the BIP process to introduce a fixed initial table for the mapping between IDs and commands. Murch suggests using the first bit to signal a 2-byte message ID, with less prevalent message types utilizing a 2-byte ID to mitigate collision risks.Pieter Wuille recently sent an email proposing the idea of using the BIP process to improve the protocol. Vasil Dimov agrees with the proposal and includes a quote from Edsger W. Dijkstra about considering the long-term implications of actions.The refreshed proposal for BIP324, a new bitcoin peer-to-peer protocol, is open for review by the community members. The proposal includes features such as opportunistic encryption, bandwidth reduction, and upgradability. Changes have been made since the last public appearance, including Elligator-swift encoding for pubkeys, x-only ECDH secret derivation, transport versioning, traffic shapability, and a shapable handshake. Links to the BIP pull request, historical and current PRs, and a gist of the previous appearance are provided for review and comments.