diff --git a/bip-0324.mediawiki b/bip-0324.mediawiki
index 6b6803a3..4e9d26a8 100644
--- a/bip-0324.mediawiki
+++ b/bip-0324.mediawiki
@@ -10,6 +10,7 @@
Type: Specification
Assigned: 2019-03-08
License: BSD-3-Clause
+ Version: 1.0.1
Replaces: 151
@@ -530,7 +531,9 @@ v2 Bitcoin P2P transport layer packets use the encrypted message structure shown
If the first byte of message_type is b'\x00', the following 12 bytes are interpreted as an ASCII message type (as in the v1 P2P protocol), trailing padded with b'\x00' as necessary. If the first byte of message_type 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.['''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.]['''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.]
-The following table lists currently defined message type IDs:
+The value of message_length is '''length''' minus the size of the message_type.
+
+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)||ADDR||BLOCK||BLOCKTXN
+|(12 bytes follow)||addr||block||blocktxn
|-
!+4
-|CMPCTBLOCK||FEEFILTER||FILTERADD||FILTERCLEAR
+|cmpctblock||feefilter||filteradd||filterclear
|-
!+8
-|FILTERLOAD||GETBLOCKS||GETBLOCKTXN||GETDATA
+|filterload||getblocks||getblocktxn||getdata
|-
!+12
-|GETHEADERS||HEADERS||INV||MEMPOOL
+|getheaders||headers||inv||mempool
|-
!+16
-|MERKLEBLOCK||NOTFOUND||PING||PONG
+|merkleblock||notfound||ping||pong
|-
!+20
-|SENDCMPCT||TX||GETCFILTERS||CFILTER
+|sendcmpct||tx||getcfilters||cfilter
|-
!+24
-|GETCFHEADERS||CFHEADERS||GETCFCHECKPT||CFCHECKPT
+|getcfheaders||cfheaders||getcfcheckpt||cfcheckpt
|-
!+28
-|ADDRV2
+|addrv2
|-
!≥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 b'\x0a' encoding and the 13-byte b'\x00getblocktxn\x00' 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 ==