From mboxrd@z Thu Jan 1 00:00:00 1970 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 "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.</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 <<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> > On Mon, Feb 20, 2023 at 03:22:30PM +0000, Pieter Wuille via bitcoin-de= v wrote:<br> >> On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns <<a hr= ef=3D"mailto:aj@erisian.com.au" target=3D"_blank">aj@erisian.com.au</a>>= wrote:<br> >>> On Fri, Feb 17, 2023 at 10:13:05PM +0000, Pieter Wuille via bi= tcoin-dev wrote:<br> >>>>> I think it's probably less complex to close some o= f the doors?<br> >>>>> 2) are short ids available/meaningful to send prior to= VERACK being<br> >>>>> completed?<br> >>>>> 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.<br> >>> I think you still need/want two negotiation steps -- once to t= ell each<br> >>> other what tables you know about, once to choose a mutually re= cognised<br> >>> table and specify any additions.<br> >> 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.<br> > Yeah; I was just thinking of the fact that currently the negotiation i= s:<br> ><br> >=C2=A0 =C2=A0* send your VERSION message<br> >=C2=A0 =C2=A0* see what their VERSION message is<br> ><br> >=C2=A0 =C2=A0* announce a bunch of features, depending on the version (= or service<br> >=C2=A0 =C2=A0 =C2=A0flags)<br> >=C2=A0 =C2=A0* send the VERACK (and GETADDR and final ALERT)<br> ><br> >=C2=A0 =C2=A0* wait for their announcements and VERACK<br> >=C2=A0 =C2=A0* negotiation is finished; we know everything; we're r= eady to go<br> ><br> > which only gets you two steps if you send the short id stuff as part o= f<br> > the VERSION message. Obviously you could just add an extra phase eithe= r<br> > just before or just after the VERACK, though.<br> ><br> > I suppose being able to choose your own short id mapping from day 0 wo= uld<br> > mean that every bip324 node could use a single short id mapping for al= l<br> > outgoing messages, which might also make implementation marginally eas= ier<br> > (no need to use one table for modern nodes, but also support the origi= nal<br> > table for old bip324 implementations)...<br> ><br> > Cheers,<br> > aj<br> > _______________________________________________<br> > bitcoin-dev mailing list<br> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= ank">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= /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--