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"
Subject: Re: [bitcoin-dev] Refreshed BIP324
Precedence: list

--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--