From 48c0f201aa6f1f84b78f0904b09893ea80c56999 Mon Sep 17 00:00:00 2001 From: Anthony Towns Date: Fri, 16 Jan 2026 10:04:38 +1000 Subject: [PATCH 1/3] BIP324: Add Version header and Changelog section --- bip-0324.mediawiki | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/bip-0324.mediawiki b/bip-0324.mediawiki index 6b6803a3..334f6076 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.0 Replaces: 151 @@ -583,6 +584,11 @@ 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.0 (2024-07-10) + * Marked as Final + == Rationale and References == From 4c805686529ef9e164e77c6e9d3c24f4e597f0df Mon Sep 17 00:00:00 2001 From: Anthony Towns Date: Thu, 11 Dec 2025 16:09:09 +1000 Subject: [PATCH 2/3] BIP324: supporting 1 byte message type ids means supporting the equivalent 12 byte ASCII message types --- bip-0324.mediawiki | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/bip-0324.mediawiki b/bip-0324.mediawiki index 334f6076..63cb6d71 100644 --- a/bip-0324.mediawiki +++ b/bip-0324.mediawiki @@ -10,7 +10,7 @@ Type: Specification Assigned: 2019-03-08 License: BSD-3-Clause - Version: 1.0.0 + Version: 1.0.1 Replaces: 151 @@ -531,7 +531,7 @@ 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 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" |- @@ -542,35 +542,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 ==== @@ -586,6 +587,8 @@ For development and testing purposes, we provide a collection of test vectors in == 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 From 40e6634a2e8bfe3089e4565ecd361ffddb78e544 Mon Sep 17 00:00:00 2001 From: Anthony Towns Date: Thu, 11 Dec 2025 16:44:50 +1000 Subject: [PATCH 3/3] BIP324: define message_length --- bip-0324.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0324.mediawiki b/bip-0324.mediawiki index 63cb6d71..4e9d26a8 100644 --- a/bip-0324.mediawiki +++ b/bip-0324.mediawiki @@ -531,6 +531,8 @@ 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 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"