From: Pieter Wuille <bitcoin-dev@wuille•net>
To: Dhruv M <dhruv@bip324•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Refreshed BIP324
Date: Wed, 26 Oct 2022 16:39:02 +0000 [thread overview]
Message-ID: <zxv58iXZ73hf9ge8S0QLTanW-uLzaWjNtMHuKONP9hrqS5RhwitxzfVaMH8hbi3yImgNrKme3lCuDcHYKkpxEQHyGZZHJ8xtReOcnAx3o4g=@wuille.net> (raw)
In-Reply-To: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com>
Hi all,
On Saturday, October 8th, 2022 at 8:59 AM, Dhruv M <dhruv@bip324•com> wrote:
> We have refreshed the proposal for BIP324, a new bitcoin P2P protocol
> featuring opportunistic encryption, a mild bandwidth reduction, and the
> ability
> to negotiate upgrades before exchanging application messages. We'd like
> to invite community members to review the BIP[1] and the related Bitcoin
> Core
> code[2].
One open question we have regarding BIP324's design is how to deal with the
coordination of assigning the message type IDs.
For context, the current BIP324 draft introduces a notion of 1-byte message
type IDs, which take the place of the 12-byte command strings (in a backward
compatible way; it's still possible to send full strings). This offers a
mild bandwidth reduction (3 bytes per message overall), especially since many
messages on the network are fairly small.
However, it obviously raises the question of how the mapping table between the
1-byte IDs and the commands they represent should be maintained:
1. The most straightforward solution is using the BIP process as-is: let BIP324
introduce a fixed initial table, and future BIPs which introduce new
messages can introduce new mapping entries for it. In theory, this is no
worse than the current coordination difficulty about command strings, but
in practice the risk of collisions due to competing proposals is of course
significantly larger with 1-byte IDs vs. 12-byte strings.
2. An alternative approach is not using 1-byte IDs but slightly longer ones;
for example 3-byte IDs, each consisting of a 2-byte BIP number and a 1-byte
message index introduced by that BIP, at the cost of a smaller bandwidth
improvement. This significantly reduces collision risks, but doesn't remove
the coordination process concerns entirely (e.g. revisions changing what a
BIP introduces need to be taken into account and probably still mean BIPs
need to explicitly list which assignments they introduce).
3. Yet another possibility is not having a fixed table at all, and negotiate
the mapping dynamically. E.g. either side could send a message at
connection time with an explicit table of entries "when I send byte X, I
mean command Y".
4. Lastly, the whole feature could just be dropped from BIP324 (sticking with
command strings), and left for a follow-up (or independent) protocol
improvement. Since arguably this is purely an application-layer concern and
not a transport-layer one, it could even be added as an optional feature to
the (pre-BIP324) protocol today. That would however very likely mean that
BIP324 if adopted as-is isn't actually an (albeit small) bandwidth
reduction compared to today, and forego a possibility to fix a fairly
gratuitous inefficiency in the protocol from day one.
Our idea is to start out with approach (1), with a mapping table effectively
managed by the BIP process directly, but if and when collisions become a
concern (maybe due to many parallel proposals, maybe because the number of
messages just grows too big), switch to approach (3), possibly even
differentially (the sent mappings are just additions/overwrites of the
BIP-defined table mappings, rather than a full mapping).
That said, we're not all that convinced this is the best approach, and feel
this more a community/process question than a technical one, so it would be
good to see more opinions on the topic.
Cheers,
--
Dhruv, Pieter, Tim
next prev parent reply other threads:[~2022-10-26 16:39 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 [this message]
2022-10-27 7:28 ` Vasil Dimov
2022-11-03 17:53 ` Murch
2022-11-03 22:26 ` Jonas Schnelli
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='zxv58iXZ73hf9ge8S0QLTanW-uLzaWjNtMHuKONP9hrqS5RhwitxzfVaMH8hbi3yImgNrKme3lCuDcHYKkpxEQHyGZZHJ8xtReOcnAx3o4g=@wuille.net' \
--to=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dhruv@bip324$(echo .)com \
/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