Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 34B40C002B for ; Tue, 28 Feb 2023 21:02:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 0297D40126 for ; Tue, 28 Feb 2023 21:02:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0297D40126 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=aJKxezFO X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 v2btSdKQtDP7 for ; Tue, 28 Feb 2023 21:02:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 86590400C8 Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) by smtp2.osuosl.org (Postfix) with ESMTPS id 86590400C8 for ; Tue, 28 Feb 2023 21:02:55 +0000 (UTC) Received: by mail-vs1-xe2e.google.com with SMTP id d7so17215652vsj.2 for ; Tue, 28 Feb 2023 13:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=OZRO+SUD8LRdAr9F/ZYRorsY2xLOuh7krWNoO3NVhtY=; b=aJKxezFO3XZ8D9zBoEqFyPr3l5uVJr3WoOV9SGfufJkTqWD91SDmqySsW/c+0j80K7 aCZi2KQW+GnkEf0dndhdxN4pTUVxWUp/I85+hRjw4rcQl7+s5TFrCQ3X6b+zd1xOlz64 AkceYge5y0Soy3XQUDWPzbpdWP+9fNVqguWvblrP88FV2qg9IdS+OqFhg6nHn3PMAona jPqLExb6sZdXYEwqGjrj70eacTwXx2dXvFsVFnsLNi2mc4pnNQwT4UckYY1kTUPI2ozH 1xxNfuRJ+2xastXlxbMkp3VGAHle0pPs3c0bhXcmwX+DgQxdcLTO7Og0wQ0QthzpVvNj HosQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OZRO+SUD8LRdAr9F/ZYRorsY2xLOuh7krWNoO3NVhtY=; b=T0Rz7dceHKJjucN8BS+lnfI1Yt04UPT9BuYSpu7+pQjRD2dKn9vQU50LFg26ZBDGvC g9DqL/4pE76qrOHPlS5rQ0YTwLeo+Ibuq0LRCnhWILJMoIqsThqvk6LsBx/3ONdk8oN8 AhnJRqKA/k8uEHh3RL7p55JqVa6L7gYCbjxVnQ3Ij/Oph+RvWIB12lac6l/7mG88h+Sm 8eoU5fI2W3AFPAxYHlbwO8RFzdUmnIgCZCxKNCgVySdIwYu8+tdIpsMY5yAtNou3CXtM 0S8SIqtxVpeEppWXvLvXTBzJKLA8uP0MkMx8K8gW5pWdarrmOZL2fndbUgsFuRVDQzK8 9qlw== X-Gm-Message-State: AO0yUKXzidOUfrthC90HgCIsFCHeJg8Ak4UULWeKUb2iqgQVm9xKJyTy uzP3EkPkQrrTIMXFRhqfMUcNFtkG76q0OyeOf1FMPBWOUzVKs5w= X-Google-Smtp-Source: AK7set9Zm4vDvr67zBRSTDfxZY/XIITrGWYldK31nxtgqKJPUuNWvEoV9jYUz/nYtWM0ViMnAKBNcXI/kutbMCB+qBk= X-Received: by 2002:a67:e8c3:0:b0:411:a740:c3ea with SMTP id y3-20020a67e8c3000000b00411a740c3eamr3069315vsn.0.1677618174122; Tue, 28 Feb 2023 13:02:54 -0800 (PST) MIME-Version: 1.0 References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com> <6b83c32e-59ca-65ef-2553-d66f8d117e56@bip324.com> <1zGcFRzB9Has9bXWlYaOXXnOy9jxwLJvhkL_46OlA8JRsx2ultkYweDdPnW3Tbf145byXb8cG8pimWBT0qBBDaKisufJufP2wssDtigKass=@wuille.net> In-Reply-To: From: Erik Aronesty Date: Tue, 28 Feb 2023 16:02:41 -0500 Message-ID: To: Dhruv M , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000565e5905f5c8ebb3" X-Mailman-Approved-At: Tue, 28 Feb 2023 21:32:40 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2023 21:02:57 -0000 --000000000000565e5905f5c8ebb3 Content-Type: text/plain; charset="UTF-8" you can always do what protocols usually do. 1 byte is fine for now, but reserve the top bit for "this is a two byte id" (128 choices). then when you run out of room, set the top bit which means "this is a 2 byte id (again with one reserved) and so-on. ie: how protobuf stores integers. On Tue, Feb 28, 2023 at 1:42 PM Dhruv M via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > 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 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000565e5905f5c8ebb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
you can always do what protocols=C2=A0usually=C2=A0do.=C2= =A0 =C2=A01 byte is fine for now, but reserve the top bit for "this is= a two byte id" (128 choices).=C2=A0 =C2=A0then when you run out of ro= om, set the top bit which means "this is a 2 byte id (again with one r= eserved) and so-on.=C2=A0 =C2=A0ie: how protobuf stores integers.

=
On Tue, Fe= b 28, 2023 at 1:42 PM Dhruv M via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org&g= t; wrote:
The re= levant 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-de= v 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 bi= tcoin-dev wrote:
>>>>> I think it's probably less complex to close some o= f 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 b= e possible to introduce a way to negotiate a different short id mapping tab= le without needing a mechanism for re-negotiating.
>>> I think you still need/want two negotiation steps -- once to t= ell each
>>> other what tables you know about, once to choose a mutually re= cognised
>>> table and specify any additions.
>> Right, I wasn't talking about how many steps/messages the nego= tiation takes. I just meant that if all negotiation of the mapping table ha= ppens just once (before VERACK) and that negotiation itself happens without= use of short commands, then there is no need for re-negotiating short comm= ands after they are already in use. Nothing concrete, but I can imagine tha= t that may simplify some implementations.
> Yeah; I was just thinking of the fact that currently the negotiation i= s:
>
>=C2=A0 =C2=A0* send your VERSION message
>=C2=A0 =C2=A0* see what their VERSION message is
>
>=C2=A0 =C2=A0* announce a bunch of features, depending on the version (= or service
>=C2=A0 =C2=A0 =C2=A0flags)
>=C2=A0 =C2=A0* send the VERACK (and GETADDR and final ALERT)
>
>=C2=A0 =C2=A0* wait for their announcements and VERACK
>=C2=A0 =C2=A0* negotiation is finished; we know everything; we're r= eady to go
>
> which only gets you two steps if you send the short id stuff as part o= f
> the VERSION message. Obviously you could just add an extra phase eithe= r
> just before or just after the VERACK, though.
>
> I suppose being able to choose your own short id mapping from day 0 wo= uld
> mean that every bip324 node could use a single short id mapping for al= l
> outgoing messages, which might also make implementation marginally eas= ier
> (no need to use one table for modern nodes, but also support the origi= nal
> table for old bip324 implementations)...
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000565e5905f5c8ebb3--