Skip to content

Commit 4c80568

Browse files
committed
BIP324: supporting 1 byte message type ids means supporting the equivalent 12 byte ASCII message types
1 parent 48c0f20 commit 4c80568

File tree

1 file changed

+14
-11
lines changed

1 file changed

+14
-11
lines changed

bip-0324.mediawiki

Lines changed: 14 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@
1010
Type: Specification
1111
Assigned: 2019-03-08
1212
License: BSD-3-Clause
13-
Version: 1.0.0
13+
Version: 1.0.1
1414
Replaces: 151
1515
</pre>
1616

@@ -531,7 +531,7 @@ v2 Bitcoin P2P transport layer packets use the encrypted message structure shown
531531
532532
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>
533533
534-
The following table lists currently defined message type IDs:
534+
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:
535535
536536
{| class="wikitable"
537537
|-
@@ -542,35 +542,36 @@ The following table lists currently defined message type IDs:
542542
!3
543543
|-
544544
!+0
545-
|(12 bytes follow)||<code>ADDR</code>||<code>BLOCK</code>||<code>BLOCKTXN</code>
545+
|(12 bytes follow)||<code>addr</code>||<code>block</code>||<code>blocktxn</code>
546546
|-
547547
!+4
548-
|<code>CMPCTBLOCK</code>||<code>FEEFILTER</code>||<code>FILTERADD</code>||<code>FILTERCLEAR</code>
548+
|<code>cmpctblock</code>||<code>feefilter</code>||<code>filteradd</code>||<code>filterclear</code>
549549
|-
550550
!+8
551-
|<code>FILTERLOAD</code>||<code>GETBLOCKS</code>||<code>GETBLOCKTXN</code>||<code>GETDATA</code>
551+
|<code>filterload</code>||<code>getblocks</code>||<code>getblocktxn</code>||<code>getdata</code>
552552
|-
553553
!+12
554-
|<code>GETHEADERS</code>||<code>HEADERS</code>||<code>INV</code>||<code>MEMPOOL</code>
554+
|<code>getheaders</code>||<code>headers</code>||<code>inv</code>||<code>mempool</code>
555555
|-
556556
!+16
557-
|<code>MERKLEBLOCK</code>||<code>NOTFOUND</code>||<code>PING</code>||<code>PONG</code>
557+
|<code>merkleblock</code>||<code>notfound</code>||<code>ping</code>||<code>pong</code>
558558
|-
559559
!+20
560-
|<code>SENDCMPCT</code>||<code>TX</code>||<code>GETCFILTERS</code>||<code>CFILTER</code>
560+
|<code>sendcmpct</code>||<code>tx</code>||<code>getcfilters</code>||<code>cfilter</code>
561561
|-
562562
!+24
563-
|<code>GETCFHEADERS</code>||<code>CFHEADERS</code>||<code>GETCFCHECKPT</code>||<code>CFCHECKPT</code>
563+
|<code>getcfheaders</code>||<code>cfheaders</code>||<code>getcfcheckpt</code>||<code>cfcheckpt</code>
564564
|-
565565
!+28
566-
|<code>ADDRV2</code>
566+
|<code>addrv2</code>
567567
|-
568568
!&geq;29
569569
|| colspan="4" | (undefined)
570570
|}
571571
572+
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).
572573
573-
Additional message types may be added separately after BIP finalization.
574+
Additional message type IDs may be added separately after BIP finalization.
574575
575576
=== Signaling specification ===
576577
==== Signaling v2 support ====
@@ -586,6 +587,8 @@ For development and testing purposes, we provide a collection of test vectors in
586587
587588
== Changelog ==
588589
590+
* 1.0.1 (2026-01-16)
591+
* Specify equivalence of 1-byte and 13-byte `message_type`
589592
* 1.0.0 (2024-07-10)
590593
* Marked as Final
591594

0 commit comments

Comments
 (0)