BIP 324: Clarify equivalence between 1 and 13 byte message types #2086

1. 
   ajtowns commented at 0:36 am on January 16, 2026: contributor

   BIP 324 introduced single-byte short identifiers for messages used multiple times in a connection, relating them to existing v1 messages, however it left it ambiguous as to what should happen if a 13-byte message_type was received. Clarify that the single byte message types are simply aliases for the longer equivalents, and that nodes should behave identically whether a message uses a one byte message_type or the equivalent 13-byte message type.

   Also lowercases the message types (matching the on-the-wire encoding, rather than the Bitcoin Core constants), explicitly defines the payload’s message_length, and adds a Version header and Changelog section.

2. BIP324: Add Version header and Changelog section 48c0f201aa
3. BIP324: supporting 1 byte message type ids means supporting the equivalent 12 byte ASCII message types 9cebeb638a
4. BIP324: define message_length ceba90c7db
5. 
   ajtowns commented at 0:51 am on January 16, 2026: contributor

   cc @sipa @real-or-random @dhruv @jonasschnelli

   I believe Bitcoin Core and btcd match this spec, but that rust-bitcoin does not, and will instead reject messages that don’t use the assigned short id. (Likewise for floresta and the bip324 crate, AIUI)

   The rationale is twofold:

   • keep things simple and avoid creating two distinct namespaces for message types – every message has a 12 byte name that’s suitable for v1/v2, and some of those message have a short, one byte alias
   • having short ids be an alias for the longer id makes dynamic allocation of short ids more straightforward: you just need to link the new short id with the 12-byte ASCII id; and if a short id is not allocated, you can reliably just use the 12-byte ASCII id.

Contributors
ajtowns