From: Jonas Schnelli <dev@jonasschnelli•ch>
To: Murch <murch@murch•one>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Refreshed BIP324
Date: Thu, 3 Nov 2022 12:26:54 -1000 [thread overview]
Message-ID: <87FFCF31-946A-44AE-8AAE-6FA3E6465C89@jonasschnelli.ch> (raw)
In-Reply-To: <d4272a20-b2a7-4ad8-9b41-8ce2b7ce827d@murch.one>
> From what I understand we'll have about 35 message types on the network with the addition of BIP324. 256 possible IDs sounds like plenty room to grow, but perhaps we can be a bit more conservative:
>
> We could use the first bit to signal a 2-byte message ID. That allows us to express 128 IDs with 1 byte, but if we need more, we get a total of 2^15 IDs across 2 bytes.
Could make sense.
There would be an alternative to preserve more 1 byte IDs on the cost of a (much) smaller 2 byte ID space:
Reserve the short ID 0xFF as an indication for a 2 bytes short ID (additional 256 short IDs with 2 bytes).
That could be done later outside BIP324.
The 0xFF approach would lead to approx. 207 unused 1 byte short IDs (while Murchs approach would give us approx. 79 unused 1 byte short IDs).
The signal bit two byte approach would however lead to ~32k more two byte message IDs.
The main (and only?) benefit of short IDs is bandwidth.
Short ID 1-12 are reserved for string based IDs and thus, new and rarely sent message types must not always use a short ID.
Maybe the BIP should state that only frequent sent messages should reserve a short ID, though, the BIP itself assigns short IDs to all(?) message types (including low frequent messages like SENDHEADERS).
Maybe exclude message types that expected to be only sent once from assigning a short ID?
/j
next prev parent reply other threads:[~2022-11-03 22:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-08 12:59 Dhruv M
2022-10-26 16:39 ` Pieter Wuille
2022-10-27 7:28 ` Vasil Dimov
2022-11-03 17:53 ` Murch
2022-11-03 22:26 ` Jonas Schnelli [this message]
2022-11-08 3:20 ` Anthony Towns
2022-11-10 21:23 ` Pieter Wuille
2022-11-12 3:23 ` Pieter Wuille
2022-11-12 18:52 ` Yuval Kogman
2022-11-18 8:24 ` Anthony Towns
2023-01-05 22:06 ` Pieter Wuille
2023-01-05 23:12 ` Anthony Towns
2023-01-09 8:11 ` Anthony Towns
2023-02-16 17:43 ` Dhruv M
2023-02-17 15:51 ` Anthony Towns
2023-02-17 22:13 ` Pieter Wuille
2023-02-19 23:56 ` Anthony Towns
2023-02-20 15:22 ` Pieter Wuille
2023-02-21 16:03 ` Anthony Towns
2023-02-28 18:07 ` Dhruv M
2023-02-28 21:02 ` Erik Aronesty
2023-10-11 20:52 ` Tim Ruffing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87FFCF31-946A-44AE-8AAE-6FA3E6465C89@jonasschnelli.ch \
--to=dev@jonasschnelli$(echo .)ch \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=murch@murch$(echo .)one \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox