path: root/ba/2061bbe2383093020fe13cfe9a2290ea03b6b7

Return-Path: <earonesty@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 34B40C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 28 Feb 2023 21:02:55 +0000 (UTC)
Received: by mail-vs1-xe2e.google.com with SMTP id d7so17215652vsj.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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>
 <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>
 <f57b879d-a1f1-43c8-2557-874b1456d972@bip324.com>
In-Reply-To: <f57b879d-a1f1-43c8-2557-874b1456d972@bip324.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 28 Feb 2023 16:02:41 -0500
Message-ID: <CAJowKg+gOTCE=S2KYTF9j-uPYysUZJsJty5CHkkVp6+Ugy6Vtw@mail.gmail.com>
To: Dhruv M <dhruv@bip324.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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 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

<div dir=3D"ltr">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 &quot;this is=
 a two byte id&quot; (128 choices).=C2=A0 =C2=A0then when you run out of ro=
om, set the top bit which means &quot;this is a 2 byte id (again with one r=
eserved) and so-on.=C2=A0 =C2=A0ie: how protobuf stores integers.</div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Fe=
b 28, 2023 at 1:42 PM Dhruv M via bitcoin-dev &lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The re=
levant changes from this discussion about short 1-byte message<br>
type IDs are now in a PR for the bips repo:<br>
<a href=3D"https://github.com/bitcoin/bips/pull/1428" rel=3D"noreferrer" ta=
rget=3D"_blank">https://github.com/bitcoin/bips/pull/1428</a><br>
<br>
On 2/21/23 08:03, Anthony Towns via bitcoin-dev wrote:<br>
&gt; On Mon, Feb 20, 2023 at 03:22:30PM +0000, Pieter Wuille via bitcoin-de=
v wrote:<br>
&gt;&gt; On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns &lt;<a hr=
ef=3D"mailto:aj@erisian.com.au" target=3D"_blank">aj@erisian.com.au</a>&gt;=
 wrote:<br>
&gt;&gt;&gt; On Fri, Feb 17, 2023 at 10:13:05PM +0000, Pieter Wuille via bi=
tcoin-dev wrote:<br>
&gt;&gt;&gt;&gt;&gt; I think it&#39;s probably less complex to close some o=
f the doors?<br>
&gt;&gt;&gt;&gt;&gt; 2) are short ids available/meaningful to send prior to=
 VERACK being<br>
&gt;&gt;&gt;&gt;&gt; completed?<br>
&gt;&gt;&gt;&gt;&gt; Ah, I hadn&#39;t considered this nuance. If we don&#39=
;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.<br>
&gt;&gt;&gt; I think you still need/want two negotiation steps -- once to t=
ell each<br>
&gt;&gt;&gt; other what tables you know about, once to choose a mutually re=
cognised<br>
&gt;&gt;&gt; table and specify any additions.<br>
&gt;&gt; Right, I wasn&#39;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.<br>
&gt; Yeah; I was just thinking of the fact that currently the negotiation i=
s:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0* send your VERSION message<br>
&gt;=C2=A0 =C2=A0* see what their VERSION message is<br>
&gt;<br>
&gt;=C2=A0 =C2=A0* announce a bunch of features, depending on the version (=
or service<br>
&gt;=C2=A0 =C2=A0 =C2=A0flags)<br>
&gt;=C2=A0 =C2=A0* send the VERACK (and GETADDR and final ALERT)<br>
&gt;<br>
&gt;=C2=A0 =C2=A0* wait for their announcements and VERACK<br>
&gt;=C2=A0 =C2=A0* negotiation is finished; we know everything; we&#39;re r=
eady to go<br>
&gt;<br>
&gt; which only gets you two steps if you send the short id stuff as part o=
f<br>
&gt; the VERSION message. Obviously you could just add an extra phase eithe=
r<br>
&gt; just before or just after the VERACK, though.<br>
&gt;<br>
&gt; I suppose being able to choose your own short id mapping from day 0 wo=
uld<br>
&gt; mean that every bip324 node could use a single short id mapping for al=
l<br>
&gt; outgoing messages, which might also make implementation marginally eas=
ier<br>
&gt; (no need to use one table for modern nodes, but also support the origi=
nal<br>
&gt; table for old bip324 implementations)...<br>
&gt;<br>
&gt; Cheers,<br>
&gt; aj<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000565e5905f5c8ebb3--