Date: Tue, 28 Feb 2023 18:07:06 +0000
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
Subject: Re: [bitcoin-dev] Refreshed BIP324
Precedence: list

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