1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
Return-Path: <bitcoin-dev@wuille.net>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id CEABDC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Oct 2022 16:39:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 8EE7D60D60
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Oct 2022 16:39:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8EE7D60D60
Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=wuille.net header.i=@wuille.net header.a=rsa-sha256
header.s=protonmail3 header.b=cZbHsTzj
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Cpn9pGX3wgye
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Oct 2022 16:39:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 17CE260D5F
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23])
by smtp3.osuosl.org (Postfix) with ESMTPS id 17CE260D5F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Oct 2022 16:39:15 +0000 (UTC)
Date: Wed, 26 Oct 2022 16:39:02 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net;
s=protonmail3; t=1666802351; x=1667061551;
bh=RljDcgl1drjhOUEPr7qWHr+jRHNbF3XWIlJRK5T2yCM=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=cZbHsTzjS4yH8BsVqUHC9xsWYlfYyNpgCTA98IjFtff+Kig4v0UHzEFD2xcvsLmqG
mRjxFtn0Am8Fe6QpwYBhpgVDpGgmr8bmbyEHOcdyoDfZ0K/XGYi4SZ4w/Dv+PY95W3
ky+j30k3r5iRSE4Ze/dP5J14351KeaYIOH+89vfhUz/LE1ws04Ar4Hyj95mVPDfYHR
TAhZHmJLRKN7oqhxW3b/jO8VjrzmORju8ywAd1DxfVttRnV0i6sx6Upe/Y6vuFzFEm
jyYPvbRUDr0B7R8OnZdYdF/J4FP35LlOREOLLWzg1dKRV2y74H6kxq7qZwOuY3O1d6
BzpXOivHBBgBA==
To: Dhruv M <dhruv@bip324.com>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <zxv58iXZ73hf9ge8S0QLTanW-uLzaWjNtMHuKONP9hrqS5RhwitxzfVaMH8hbi3yImgNrKme3lCuDcHYKkpxEQHyGZZHJ8xtReOcnAx3o4g=@wuille.net>
In-Reply-To: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com>
References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com>
Feedback-ID: 19463299:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 26 Oct 2022 22:01:28 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Refreshed BIP324
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Oct 2022 16:39:18 -0000
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 backwar=
d
compatible way; it's still possible to send full strings). This offers a
mild bandwidth reduction (3 bytes per message overall), especially since ma=
ny
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 BI=
P324
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, bu=
t
in practice the risk of collisions due to competing proposals is of cour=
se
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-b=
yte
message index introduced by that BIP, at the cost of a smaller bandwidth
improvement. This significantly reduces collision risks, but doesn't rem=
ove
the coordination process concerns entirely (e.g. revisions changing what=
a
BIP introduces need to be taken into account and probably still mean BIP=
s
need to explicitly list which assignments they introduce).
3. Yet another possibility is not having a fixed table at all, and negotiat=
e
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 wi=
th
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 tha=
t
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 effectivel=
y
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,
--=20
Dhruv, Pieter, Tim
|
