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

BIP324: supporting 1 byte message type ids means supporting the equivalent 12 byte ASCII message types

Browse Source
This commit is contained in:
Anthony Towns 2025-12-11 16:09:09 +10:00
parent 48c0f201aa
commit 4c80568652
1 changed files with 14 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
bip-0324.mediawiki
View File

@ -10,7 +10,7 @@
Type: Specification
Assigned: 2019-03-08
License: BSD-3-Clause
Version: 1.0.0
Version: 1.0.1
Replaces: 151
</pre>
@ -531,7 +531,7 @@ 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 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)||<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 ====
@ -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