From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1A3E7C002D for ; 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 ; 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 ; 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 ; Sat, 12 Nov 2022 18:52:45 +0000 (UTC) Received: by mail-lf1-x134.google.com with SMTP id r12so13073854lfp.1 for ; 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> In-Reply-To: From: Yuval Kogman Date: Sat, 12 Nov 2022 20:52:31 +0200 Message-ID: To: Pieter Wuille , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
On Sat, 12 Nov 2022, 11:01 Pieter W= uille via bitcoin-dev, <bitcoin-dev@lists.linuxfoundation.org> wr= ote:
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 bi= t of byte 11 has no special meaning).
...=C2=A0
<= 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.

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 "no [...] nee= d for thinking of [them] as distinct" logic a little bit bit farther.<= /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.
--000000000000e92c6d05ed4a82e9--