path: root/43/f3aa5504cff20388c6994b34db3cefbf3129f3

Return-Path: <nothingmuch@woobling.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1A3E7C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Nov 2022 18:52:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id D74BA40465
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Nov 2022 18:52:47 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D74BA40465
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (1024-bit key) header.d=woobling.org header.i=@woobling.org
 header.a=rsa-sha256 header.s=google header.b=RWt3qMZC
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 xayM8OGKniZE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Nov 2022 18:52:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8549D400DB
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
 [IPv6:2a00:1450:4864:20::134])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 8549D400DB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Nov 2022 18:52:45 +0000 (UTC)
Received: by mail-lf1-x134.google.com with SMTP id r12so13073854lfp.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Nov 2022 10:52:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=woobling.org; s=google;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=L0bAoCIZTaU5W9EKXAzF7qWkGFVhhiphfihOzSmNU50=;
 b=RWt3qMZCAooG3Mk8beQ2a40D/W3JW5fWn14XDaCVWkonhFL1froRLXf/aVNCV/0Dt+
 I02e+5gXvN+KKCEry2S8Y3zAZRoaz1l0yJno05vBvnL3MzGf5YeViPcwcqtp0GLv+EOF
 QbYI8pZkjRIG/d053+ClMd29or+JtYxEKcUcE=
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=L0bAoCIZTaU5W9EKXAzF7qWkGFVhhiphfihOzSmNU50=;
 b=yZF8wseOjOzpz636AbdLxX6uJAY9NjbUA5wpwQTr6nk/flqv+fxJA3f9VNajIIDq5v
 8PhMgfjhv/FjRZqaMQO+pi8yb4MWlFfK3m0OeRK5BRiUvKp3NMt+efFRNUEHmta5NT58
 5M7FTOc1p+LuuNx3/EgcxQLtVMnn9EsdxaRpUgW4n9djA6sm1RBwG8ohnACvHCu6DQND
 iz6DKyJ9q/NQEq1PKeQGYrKW9cSs5i+PTlkG2gSgFw5/1oqGfRFJ7RBreHwdajk5v0V3
 P7R+CirbmBDe6GFhCoz63ACxMJBFOMW2XiPxgZAKdqQmWJOtvtJIufolfe0QIN704KE/
 agvg==
X-Gm-Message-State: ANoB5pmAUJUN68q+gQt2mFBlR3BtH/jhO0C9ksYBowk46R6LJ8y7xBNv
 y6fGuMtvm1H4MH4/KqHKVZqofLRL0/CTH7ALb8FRSnpMY0UaCM9R
X-Google-Smtp-Source: AA0mqf5/4KYtky3Vx1yU/gH/QGz2zbEzMbe4C/PHe9b53ZMzCJtPl3uUFb7FdS3QOUJ7z0x+rX53A1IDWJNqyGGTlm4=
X-Received: by 2002:ac2:4c55:0:b0:4b0:38df:e825 with SMTP id
 o21-20020ac24c55000000b004b038dfe825mr2660005lfk.471.1668279163227; Sat, 12
 Nov 2022 10:52:43 -0800 (PST)
MIME-Version: 1.0
References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com>
 <zxv58iXZ73hf9ge8S0QLTanW-uLzaWjNtMHuKONP9hrqS5RhwitxzfVaMH8hbi3yImgNrKme3lCuDcHYKkpxEQHyGZZHJ8xtReOcnAx3o4g=@wuille.net>
 <Y2nK99fHUKxbPHmw@erisian.com.au>
 <wDqcIVw-YGTsjdf5M2GO9NNRl_UQuBeka2CUQUyQ329u6u-o7RabW_7S4FD3EDfk02kUczb3bXf8LtHhKLtx773UhQ7djKOl-JPOIrXqBSc=@wuille.net>
 <JXfTBjsA71dHE3h9wkxnWXANrwTbMADO4s2w34gEvMbiduKu4PEt5t-KA3EAIz-Xs4urjBHZ15NDFZST2a7e0x_NqyJymUnEORuTp3SNfMs=@wuille.net>
In-Reply-To: <JXfTBjsA71dHE3h9wkxnWXANrwTbMADO4s2w34gEvMbiduKu4PEt5t-KA3EAIz-Xs4urjBHZ15NDFZST2a7e0x_NqyJymUnEORuTp3SNfMs=@wuille.net>
From: Yuval Kogman <nothingmuch@woobling.org>
Date: Sat, 12 Nov 2022 20:52:31 +0200
Message-ID: <CAAQdECCibMp+=SfmNW0LfJX=0WZtM5TMw6qWuS9qVUHcvJTBOg@mail.gmail.com>
To: Pieter Wuille <bitcoin-dev@wuille.net>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e92c6d05ed4a82e9"
X-Mailman-Approved-At: Sat, 12 Nov 2022 18:53:25 +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: Sat, 12 Nov 2022 18:52:48 -0000

--000000000000e92c6d05ed4a82e9
Content-Type: text/plain; charset="UTF-8"

On Sat, 12 Nov 2022, 11:01 Pieter Wuille via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I think we can just merge the two and have a single variable-length
> command structure that can be used for both: command encodings are 1 to 12
> bytes, each byte's top bit indicating whether another byte follows (the top
> bit of byte 11 has no special meaning).
>
...

> So this gives a uniform space which commands can be assigned from, and
> there is no strict need for thinking of the short-binary and
> long-alphabetic commands as distinct.In v2, some short ones would be
> treated as aliases for old long-alphabetic ones.


This seems a bit dubious, but since command names are ASCII strings
reversing the meaning of the top bit so that 0 signifies a following byte
would allow the alphabetic commands to be reinterpreted as non-alphabetic,
so the space no longer needs to be a disjoint union of two sub-spaces which
arguably takes the "no [...] need for thinking of [them] as distinct" logic
a little bit bit farther.

The main downsides are that this does nothing to re-assign shorter codes to
existing commands, and secondly that even the non-alphabetic code path
completely supersedes the alphabetic one, the numerical values are up to 85
or 86 bits wide, which is not a reasonable word size. Perhaps this is not a
concern since as far as I know there are no collisions in the first 9 bytes
of existing commands, and constrain the non-alphabetic representation to 9
bytes would leave the last top bit free, so the space would be isomorphic
to {0,1}^64.

--000000000000e92c6d05ed4a82e9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"auto"><div>On Sat, 12 Nov 2022, 11:01 Pieter W=
uille via bitcoin-dev, &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<br></div><div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">
I think we can just merge the two and have a single variable-length command=
 structure that can be used for both: command encodings are 1 to 12 bytes, =
each byte&#39;s top bit indicating whether another byte follows (the top bi=
t of byte 11 has no special meaning).<br></blockquote><div>...=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
So this gives a uniform space which commands can be assigned from, and ther=
e is no strict need for thinking of the short-binary and long-alphabetic co=
mmands as distinct.In v2, some short ones would be treated as aliases for o=
ld long-alphabetic ones.</blockquote><div><div><br class=3D"gmail-Apple-int=
erchange-newline"></div></div><div><div><div>This seems a bit dubious, but =
since command names are ASCII strings reversing the meaning of the top bit =
so that 0 signifies a following byte would allow the alphabetic commands to=
 be reinterpreted as non-alphabetic, so the space no longer needs to be a d=
isjoint union of two sub-spaces which arguably takes the &quot;no [...] nee=
d for thinking of [them] as distinct&quot; logic a little bit bit farther.<=
/div><div><br></div><div>The main downsides are that this does nothing to r=
e-assign shorter codes to existing commands, and secondly that even the non=
-alphabetic code path completely supersedes the alphabetic one, the numeric=
al values are up to 85 or 86 bits wide, which is not a reasonable word size=
. Perhaps this is not a concern since as far as I know there are no collisi=
ons in the first 9 bytes of existing commands, and constrain the non-alphab=
etic representation to 9 bytes would leave the last top bit free, so the sp=
ace would be isomorphic to {0,1}^64.</div><div></div></div><div></div></div=
></div></div></div>
</div>

--000000000000e92c6d05ed4a82e9--