bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-02-09 15:23:09 +00:00
Code Issues Releases Wiki Activity

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

Browse Source 
BIP 324: Clarify equivalence between 1 and 13 byte message types
This commit is contained in:
Mark "Murch" Erhardt 2026-01-29 10:18:01 -08:00 committed by GitHub
commit 43e3983e4b
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 21 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
bip-0324.mediawiki
View File

@ -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/>