Merge pull request #2086 from ajtowns/202512-bip324-shortid-alias

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

Author: murchandamus

bip-0324.mediawiki

@@ -10,6 +10,7 @@
   Type: Specification
   Assigned: 2019-03-08
   License: BSD-3-Clause
+  Version: 1.0.1
   Replaces: 151
 </pre>
 
@@ -530,7 +531,9 @@ v2 Bitcoin P2P transport layer packets use the encrypted message structure shown
 
 If the first byte of <code>message_type</code> is <code>b'\x00'</code>, the following 12 bytes are interpreted as an ASCII message type (as in the v1 P2P protocol), trailing padded with <code>b'\x00'</code> as necessary. If the first byte of <code>message_type</code> is in the range ''1..255'', it is interpreted as a message type ID. This structure results in smaller messages than the v1 protocol, as most messages sent/received will have a message type ID. We recommend reserving 1-byte type IDs for message types that are sent more than once per direction per connection.<ref name="smaller_messages">'''How do the lengths between v1 and v2 compare?''' For messages that use the 1-byte short message type ID, v2 packets use 3 bytes less per message than v1.</ref><ref name"fixed_length_long_ids">'''Why not allow variable length long message type IDs?''' Allowing for variable length long IDs reduces the available 1-byte ID space by 12 (to encode the length itself) and incentivizes less descriptive message types. In addition, limiting message types to fixed lengths of 1 or 13 hampers traffic analysis.</ref>
 
-The following table lists currently defined message type IDs:
+The value of <code>message_length</code> is '''length''' minus the size of the <code>message_type</code>.
+
+The following table lists currently defined message type IDs and the 12-byte ASCII message type (trimmed of trailing padding) that they are treated as equivalent to:
 
 {| class="wikitable"
 |-
@@ -541,35 +544,36 @@ The following table lists currently defined message type IDs:
 !3
 |-
 !+0
-|(12 bytes follow)||<code>ADDR</code>||<code>BLOCK</code>||<code>BLOCKTXN</code>
+|(12 bytes follow)||<code>addr</code>||<code>block</code>||<code>blocktxn</code>
 |-
 !+4
-|<code>CMPCTBLOCK</code>||<code>FEEFILTER</code>||<code>FILTERADD</code>||<code>FILTERCLEAR</code>
+|<code>cmpctblock</code>||<code>feefilter</code>||<code>filteradd</code>||<code>filterclear</code>
 |-
 !+8
-|<code>FILTERLOAD</code>||<code>GETBLOCKS</code>||<code>GETBLOCKTXN</code>||<code>GETDATA</code>
+|<code>filterload</code>||<code>getblocks</code>||<code>getblocktxn</code>||<code>getdata</code>
 |-
 !+12
-|<code>GETHEADERS</code>||<code>HEADERS</code>||<code>INV</code>||<code>MEMPOOL</code>
+|<code>getheaders</code>||<code>headers</code>||<code>inv</code>||<code>mempool</code>
 |-
 !+16
-|<code>MERKLEBLOCK</code>||<code>NOTFOUND</code>||<code>PING</code>||<code>PONG</code>
+|<code>merkleblock</code>||<code>notfound</code>||<code>ping</code>||<code>pong</code>
 |-
 !+20
-|<code>SENDCMPCT</code>||<code>TX</code>||<code>GETCFILTERS</code>||<code>CFILTER</code>
+|<code>sendcmpct</code>||<code>tx</code>||<code>getcfilters</code>||<code>cfilter</code>
 |-
 !+24
-|<code>GETCFHEADERS</code>||<code>CFHEADERS</code>||<code>GETCFCHECKPT</code>||<code>CFCHECKPT</code>
+|<code>getcfheaders</code>||<code>cfheaders</code>||<code>getcfcheckpt</code>||<code>cfcheckpt</code>
 |-
 !+28
-|<code>ADDRV2</code>
+|<code>addrv2</code>
 |-
 !&geq;29
 || colspan="4" | (undefined)
 |}
 
+When a message type has both a 1-byte encoding and a 13-byte encoding defined, peers that support receiving that message type should accept messages using either encoding (e.g., if the "getblocktxn" message type is supported, then both the 1-byte <code>b'\x0a'</code> encoding and the 13-byte <code>b'\x00getblocktxn\x00'</code> should be supported, and behavior should not depend on which of the two encodings is received).
 
-Additional message types may be added separately after BIP finalization.
+Additional message type IDs may be added separately after BIP finalization.
 
 === Signaling specification ===
 ==== Signaling v2 support ====
@@ -583,6 +587,13 @@ For development and testing purposes, we provide a collection of test vectors in
 * [[bip-0324/xswiftec_inv_test_vectors.csv|XSwiftECInv vectors]] provide examples of ''(u, x)'' pairs, and the various ''t'' values that ''xswiftec_inv'' maps them to.
 * [[bip-0324/packet_encoding_test_vectors.csv|Packet encoding vectors]] illustrate the lifecycle of the authenticated encryption scheme proposed in this document.
 
+== Changelog ==
+
+ * 1.0.1 (2026-01-16)
+   * Specify equivalence of 1-byte and 13-byte `message_type`
+ * 1.0.0 (2024-07-10)
+   * Marked as Final
+
 == Rationale and References ==
 <references/>