summaryrefslogtreecommitdiff
path: root/e6/de3ddc50b5f6706d69b3c3377a9444a3c230b9
blob: a7c4755f7879150b44e6e0f2d2a5af27dbef25c2 (plain)
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
Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 22D11C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Feb 2023 16:03:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id F334741022
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Feb 2023 16:03:49 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org F334741022
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id tFr1ejNMwR1Q
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Feb 2023 16:03:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org B709C41031
Received: from cerulean.erisian.com.au (azure.erisian.com.au [172.104.61.193])
 by smtp2.osuosl.org (Postfix) with ESMTPS id B709C41031
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Feb 2023 16:03:48 +0000 (UTC)
Received: from 60.42.96.58.static.exetel.com.au ([58.96.42.60]
 helo=sapphire.erisian.com.au)
 by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)
 (envelope-from <aj@erisian.com.au>)
 id 1pUV7F-0008KL-JX; Wed, 22 Feb 2023 02:03:43 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Wed, 22 Feb 2023 02:03:37 +1000
Date: Wed, 22 Feb 2023 02:03:37 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Pieter Wuille <bitcoin-dev@wuille.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y/TrWS1Y3JkxHsQn@erisian.com.au>
References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com>
 <Y3dBUXPhTskCx+Fu@erisian.com.au>
 <gSxFQedPc72pTioi9vuxvLKpaRBsnKFL4gkPKPn2G-EJgz_2Y1pYQ7cHD5SnunyCaLln7UQEHIxnopqP74LlnK__Mf9BURbJW8B5MYTZvCU=@wuille.net>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1zGcFRzB9Has9bXWlYaOXXnOy9jxwLJvhkL_46OlA8JRsx2ultkYweDdPnW3Tbf145byXb8cG8pimWBT0qBBDaKisufJufP2wssDtigKass=@wuille.net>
X-Spam_score: -1.0
X-Spam_bar: -
Cc: Dhruv M <dhruv@bip324.com>
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, 21 Feb 2023 16:03:50 -0000

On Mon, Feb 20, 2023 at 03:22:30PM +0000, Pieter Wuille via bitcoin-dev wrote:
> 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 being available before VERACK negotiation, then it may be possible to introduce a way to negotiate a different short id mapping table without needing a mechanism 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 takes. I just meant that if all negotiation of the mapping table happens just once (before VERACK) and that negotiation itself happens without use of short 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