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
|
Return-Path: <dhruv@bip324.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7896EC002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Feb 2023 18:16:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 72DB781AAB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Feb 2023 18:16:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 72DB781AAB
Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=bip324.com header.i=@bip324.com header.a=rsa-sha256
header.s=protonmail2 header.b=PwwcJ2mT
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id YJ22RNwkmBG4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Feb 2023 18:16:01 +0000 (UTC)
X-Greylist: delayed 00:08:29 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org AFD1081A5C
Received: from mail-4327.protonmail.ch (mail-4327.protonmail.ch [185.70.43.27])
by smtp1.osuosl.org (Postfix) with ESMTPS id AFD1081A5C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Feb 2023 18:16:00 +0000 (UTC)
Date: Tue, 28 Feb 2023 18:07:06 +0000
Authentication-Results: mail-4321.protonmail.ch;
dkim=pass (2048-bit key) header.d=bip324.com header.i=@bip324.com
header.b="PwwcJ2mT"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bip324.com;
s=protonmail2; t=1677607638; x=1677866838;
bh=FkZRcVRnm2pB/b33jT/jmXex4zwMOUxFQKZsNR7kLas=;
h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=PwwcJ2mTUACrADk3Q79+RkRZ7KYlax+f83XZUkCgoppLczulx+tgp0oNmGtgBX2As
jI3izwS/2kDbqFQ/gJBuVSZNUFUlRjKJkS6WNI4tx+xbu97I0O1ku6HrDvJrTvj7im
UC+X8RQQa18Qf9cOAdft4hYurhOb9oTNjG9QuoheZJTJZpbRyjep0eqN+xE//LtGJW
bH0aMnE81s/srFZS8jUB2zlXcH1fDIV/uOzhP4BlPMKC6p+YHILMWTQVZfIXbVzrDz
DS/rSdMf1gaiLQkWTq1al5JG4gHQuneMAw4AjwOxJbANnfHcv83tEAahh2axBaypJR
dhEzTPwEMW70A==
To: bitcoin-dev@lists.linuxfoundation.org
From: Dhruv M <dhruv@bip324.com>
Message-ID: <f57b879d-a1f1-43c8-2557-874b1456d972@bip324.com>
In-Reply-To: <Y/TrWS1Y3JkxHsQn@erisian.com.au>
References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com>
<Y7dZctMlZtH6PEsz@erisian.com.au> <Y7vMGVQz8TjS4Cad@erisian.com.au>
<6b83c32e-59ca-65ef-2553-d66f8d117e56@bip324.com>
<Y++id6mXsscfxduH@erisian.com.au>
<S1zoL4CCIDVTrjmXx2JtYhO2qjgGyNIAP6X9FXRCRKPDjoQj20VcqKFCYkmmPQkNuMyNf9zp6GFVWWC7l8dBzCogUqvzmDx9D811NPheNJ8=@wuille.net>
<Y/K3Ejkwlj4NIMMa@erisian.com.au>
<1zGcFRzB9Has9bXWlYaOXXnOy9jxwLJvhkL_46OlA8JRsx2ultkYweDdPnW3Tbf145byXb8cG8pimWBT0qBBDaKisufJufP2wssDtigKass=@wuille.net>
<Y/TrWS1Y3JkxHsQn@erisian.com.au>
Feedback-ID: 44080706:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 28 Feb 2023 18:41:54 +0000
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: Tue, 28 Feb 2023 18:16:03 -0000
The relevant changes from this discussion about short 1-byte message
type IDs are now in a PR for the bips repo:
https://github.com/bitcoin/bips/pull/1428
On 2/21/23 08:03, Anthony Towns via bitcoin-dev wrote:
> On Mon, Feb 20, 2023 at 03:22:30PM +0000, Pieter Wuille via bitcoin-dev w=
rote:
>> On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns <aj@erisian.com=
.au> wrote:
>>> On Fri, Feb 17, 2023 at 10:13:05PM +0000, Pieter Wuille via bitcoin-dev=
wrote:
>>>>> I think it's probably less complex to close some of the doors?
>>>>> 2) are short ids available/meaningful to send prior to VERACK being
>>>>> completed?
>>>>> Ah, I hadn't considered this nuance. If we don't care about them bein=
g available before VERACK negotiation, then it may be possible to introduce=
a way to negotiate a different short id mapping table without needing a me=
chanism for re-negotiating.
>>> I think you still need/want two negotiation steps -- once to tell each
>>> other what tables you know about, once to choose a mutually recognised
>>> table and specify any additions.
>> Right, I wasn't talking about how many steps/messages the negotiation ta=
kes. I just meant that if all negotiation of the mapping table happens just=
once (before VERACK) and that negotiation itself happens without use of sh=
ort commands, then there is no need for re-negotiating short commands after=
they are already in use. Nothing concrete, but I can imagine that that may=
simplify some implementations.
> Yeah; I was just thinking of the fact that currently the negotiation is:
>
> * send your VERSION message
> * see what their VERSION message is
>
> * announce a bunch of features, depending on the version (or service
> flags)
> * send the VERACK (and GETADDR and final ALERT)
>
> * wait for their announcements and VERACK
> * negotiation is finished; we know everything; we're ready to go
>
> which only gets you two steps if you send the short id stuff as part of
> the VERSION message. Obviously you could just add an extra phase either
> just before or just after the VERACK, though.
>
> I suppose being able to choose your own short id mapping from day 0 would
> mean that every bip324 node could use a single short id mapping for all
> outgoing messages, which might also make implementation marginally easier
> (no need to use one table for modern nodes, but also support the original
> table for old bip324 implementations)...
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
