Published on: 2023-02-28T21:02:41+00:00
The Bitcoin Improvement Proposals (BIPs) repository has incorporated changes following a discussion on the use of short 1-byte message type IDs. The discussion focused on the complexity of the negotiation process for mapping tables and the need for re-negotiating short commands after they have been in use. It was suggested that if all negotiation of the mapping table occurs before VERACK, without using short commands, there would be no need for re-negotiating short commands. This proposal would simplify implementations and allow each BIP324 node to use a single short ID mapping for all outgoing messages.Anthony Towns shared his opinion on the negotiation process, suggesting two steps: one to share information about the tables used and another to choose a mutually recognized table and specify any additions. Pieter Wuille agreed with this but mentioned that if all negotiation of the mapping table happens just once before VERACK, there is no need for re-negotiating short commands. However, the current negotiation process involves multiple steps, and an extra phase could solve the issue. They also discussed the possibility of nodes choosing their own short ID mappings from day one, simplifying implementations.In the bitcoin-dev group, Anthony Towns suggested closing some doors to reduce complexity. They discussed using short IDs to minimize bandwidth and proposed reserving short ID 0 for long commands and using short IDs 1-255 as aliases of particular long commands. This would drop certain commands from bip 324 and potentially simplify implementations. It was also suggested to move the type ID mapping to the p2p layer away from the transport layer.The discussion on the bitcoin-dev mailing list revolved around the issue of 1-byte message type IDs lacking a co-ordination mechanism. Solutions proposed included uniform encoding using the high-bit and making type IDs negotiable per direction per connection. The proposal suggests restricting type IDs to [1, 127], removing 1 byte allocations for messages sent once per connection per direction, and possibly moving the type ID mapping to the p2p layer away from the transport layer. Technical details such as implementation for 324, serialization tables, and negotiation mechanisms were also discussed.The proposal aims to address the problem of 1-byte message type IDs lacking a co-ordination mechanism and the issue of allocating scarce 1-byte IDs judiciously. Solutions proposed include uniform encoding using the high-bit and making type IDs negotiable per direction per connection. The discussion involves technical details such as the current implementation for 324, serialization tables, and negotiation mechanisms. The proposal suggests restricting type IDs to [1, 127], removing 1 byte allocations for messages sent once per connection per direction, and potentially moving the type ID mapping to the p2p layer away from the transport layer.The discussion on the Bitcoin-dev mailing list focuses on using short IDs as a way to encode specific types of messages in the Bitcoin peer-to-peer protocol. The current implementation for 324 already includes aliasing for short IDs. The proposal suggests negotiated assignments of short IDs, allowing each peer to choose mappings that minimize their outbound traffic and don't require coordination with the other peer. This proposal has the advantages of reducing memory usage and implementation complexity. However, there are limitations in introducing short IDs for certain types of messages. Overall, the discussion explores ways to reduce outbound traffic and simplify implementations.A discussion thread on the Bitcoin-dev mailing list addresses the topic of having a uniform encoding scheme for message identifiers in the p2p protocol. Suggestions include treating short commands as aliases for long commands and having an initial assignment or explicit negotiation mechanism for 1-byte encodings. The discussion also considers moving the aliasing to the protocol layer instead of the wire layer. The goal is to make it easy to come up with a message identifier without conflicting with other proposals and to save bandwidth by using short encodings for commonly used messages. The complexity and implementation details of these suggestions are discussed.Pieter Wuille suggests a uniform encoding scheme for message identifiers in the p2p protocol, where alphabetic commands become bytes and non-alphabetic commands are assigned 1-byte or 2-byte values. The discussion questions whether this optimization is necessary and considers the goals of making message identification easy and saving bandwidth. Concerns are raised about potential conflicts when picking values from a set of elements. The proposal acknowledges the complexity involved and suggests an initial assignment or negotiation mechanism for encodings.In a recent discussion among Bitcoin developers, the allocation of message IDs in the network was addressed. One suggestion was to use "SHORTMSG" to specify supported tables and send "SENDSHORTMSG" to choose the table used for abbreviating messages. Another idea was to merge short and long command structures into a single variable-length structure.
Updated on: 2023-08-02T07:59:08.268019+00:00