path: root/7d/3d8b7b2c71c4f97185fc47d5a091e916c6fddc

Return-Path: <roconnor@blockstream.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 04801C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 16:28:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id E7FE781000
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 16:28:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 18_kTPBuBF0v
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 16:28:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com
 [IPv6:2607:f8b0:4864:20::f31])
 by smtp1.osuosl.org (Postfix) with ESMTPS id F30E980E3F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 16:28:33 +0000 (UTC)
Received: by mail-qv1-xf31.google.com with SMTP id ke15so5132862qvb.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 09:28:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=+47+skvT96F60GFCvTSMq15QhwhVG/vzX73KQLzGMzI=;
 b=GAXMSHvmwqIbFbMdH+1xicC0jmlGNEk0omBbENEEwVEwlpdrQGbe1kb0zhwtpC0E1g
 4pVJVpoZQW7VvUlgGrlmzEQF119ApTcuPAPJ0l2UK1AoF6yYfkoIIAHfVX2jcl2RnLgx
 JmX6bWyXw4a8fs93RYaEl3d9n9CSVbgD9BMX1jZVJqr3ryEHEovuqqB8HS7OnPCYkaCF
 b38Dt2VYY/jNVWx3tYo5uxOF5HdY3MTUV7Epd8HwQZaxR/bWEntfHHeaP/gz2jNVRig3
 M8sd07K8k5qmqQxY2XuCljclNHdnKtIueAm3AOzWLyR86hCZutFc6KAHUMtcQ2h57xU9
 M3+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=+47+skvT96F60GFCvTSMq15QhwhVG/vzX73KQLzGMzI=;
 b=eXOHxw/Ppf12S0+//xyRId8xb5GCQgmFTP6FKwkzqGwjRURG0uTgloy8KXA8e9Pn15
 W/alsVqtWWHE35yMzr5UzEBhg1ONJGuWBrdSFDZuhrV59ClbiSO8XYlyZSCvJyz9wyFw
 XtmZQCjiJBfrfQhdG0MkbO1OspKKewbjF9NWb8ABHeYb7sQ0xdMeR9mOQg7rLD/xgqUb
 6L2YbXxzrbEt0yOtUzNOgOLjmHs/mNqQoYDryKy3qjjLX2Tr6+HMU7Ffn1dq+vvtb2oI
 Cj6wPwyfaaYjYiBc4+QnIG0xXHI3G55kqxzEWAi7zRNmTYpTLqlLzvZE3mPONa7vjio+
 tULw==
X-Gm-Message-State: AOAM531PuC02uuxkWlIFBgLG6WnfzglRCiU9h6W3KDUkKlbz8YhATICh
 pj0bjTFrRoWvTuRWbiCkc9NPCOP+9jXIFf0fOw4nLRtHmAY=
X-Google-Smtp-Source: ABdhPJzVBB+byMrQyLk6yjPcQE5zwBEY+Glx+74JGcxzu1OJHLc7qxhwt2S9eaSGnXNxZzR3rvuREmIAw8HqTrx/jLw=
X-Received: by 2002:ad4:5dca:0:b0:441:55db:2835 with SMTP id
 m10-20020ad45dca000000b0044155db2835mr479450qvh.31.1647966512723; Tue, 22 Mar
 2022 09:28:32 -0700 (PDT)
MIME-Version: 1.0
References: <NGFW5p2Gl4t6AqL2E29THMT5DbppMJlB6bdUE6nxAdMajxeFcoRNdt5axNLql08EoyIMsBgZHHHYt_MiITZwzyGZIz0iFX4vaKIYrVV2QhU=@protonmail.com>
 <CAMZUoK=TzOFfMFwNw6gjHtu2EeEPhyL9AjqLS-T=wphc905_JA@mail.gmail.com>
 <e4r4E0AYzZzkVQp67yxIG-fBBBH8rNrl-MtM7kJXoAsDT_bBSt6gXs_ukw6bBL4845s0OPkrIRjIk54hkQP_pL8X4A--1GFtYcGAl2bW_gs=@protonmail.com>
In-Reply-To: <e4r4E0AYzZzkVQp67yxIG-fBBBH8rNrl-MtM7kJXoAsDT_bBSt6gXs_ukw6bBL4845s0OPkrIRjIk54hkQP_pL8X4A--1GFtYcGAl2bW_gs=@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Tue, 22 Mar 2022 12:28:21 -0400
Message-ID: <CAMZUoKnC0f=FCjSa9oNMhXob+P6OaMdzUKWbhAMty2Xub-40TA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000097ca2b05dad11afc"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets
 Without Softforks
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, 22 Mar 2022 16:28:35 -0000

--00000000000097ca2b05dad11afc
Content-Type: text/plain; charset="UTF-8"

Thanks for the clarification.

You don't think referring to the microcode via its hash, effectively using
32-byte encoding of opcodes, is still rather long winded?

On Tue, Mar 22, 2022 at 12:23 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Russell,
>
> > Setting aside my thoughts that something like Simplicity would make a
> better platform than Bitcoin Script (due to expression operating on a more
> narrow interface than the entire stack (I'm looking at you OP_DEPTH)) there
> is an issue with namespace management.
> >
> > If I understand correctly, your implication was that once opcodes are
> redefined by an OP_RETURN transaction, subsequent transactions of that
> opcode refer to the new microtransaction.  But then we have a race
> condition between people submitting transactions expecting the outputs to
> refer to the old code and having their code redefined by the time they do
> get confirmed  (or worse having them reorged).
>
> No, use of specific microcodes is opt-in: you have to use a specific
> `0xce` Tapscript version, ***and*** refer to the microcode you want to use
> via the hash of the microcode.
>
> The only race condition is reorging out a newly-defined microcode.
> This can be avoided by waiting for deep confirmation of a newly-defined
> microcode before actually using it.
>
> But once the microcode introduction outpoint of a particular microcode has
> been deeply confirmed, then your Tapscript can refer to the microcode, and
> its meaning does not change.
>
> Fullnodes may need to maintain multiple microcodes, which is why creating
> new microcodes is expensive; they not only require JIT compilation, they
> also require that fullnodes keep an index that cannot have items deleted.
>
>
> The advantage of the microcode scheme is that the size of the SCRIPT can
> be used as a proxy for CPU load ---- just as it is done for current Bitcoin
> SCRIPT.
> As long as the number of `UOP_` micro-opcodes that an `OP_` code can
> expand to is bounded, and we avoid looping constructs, then the CPU load is
> also bounded and the size of the SCRIPT approximates the amount of
> processing needed, thus microcode does not require a softfork to modify
> weight calculations in the future.
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr"><div>Thanks for the clarification.<br></div><div><br></div=
><div>You don&#39;t think referring to the microcode via its hash, effectiv=
ely using 32-byte encoding of opcodes, is still rather long winded?</div><d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Tue, Mar 22, 2022 at 12:23 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@proto=
nmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">Good morning Russell,<br>
<br>
&gt; Setting aside my thoughts that something like Simplicity would make a =
better platform than Bitcoin Script (due to expression operating on a more =
narrow interface than the entire stack (I&#39;m looking at you OP_DEPTH)) t=
here is an issue with namespace management.<br>
&gt;<br>
&gt; If I understand correctly, your implication was that once opcodes are =
redefined by an OP_RETURN transaction, subsequent transactions of that opco=
de refer to the new microtransaction.=C2=A0 But then we have a race conditi=
on between people submitting transactions expecting the outputs to refer to=
 the old code and having their code redefined by the time they do get confi=
rmed=C2=A0 (or worse having them reorged).<br>
<br>
No, use of specific microcodes is opt-in: you have to use a specific `0xce`=
 Tapscript version, ***and*** refer to the microcode you want to use via th=
e hash of the microcode.<br>
<br>
The only race condition is reorging out a newly-defined microcode.<br>
This can be avoided by waiting for deep confirmation of a newly-defined mic=
rocode before actually using it.<br>
<br>
But once the microcode introduction outpoint of a particular microcode has =
been deeply confirmed, then your Tapscript can refer to the microcode, and =
its meaning does not change.<br>
<br>
Fullnodes may need to maintain multiple microcodes, which is why creating n=
ew microcodes is expensive; they not only require JIT compilation, they als=
o require that fullnodes keep an index that cannot have items deleted.<br>
<br>
<br>
The advantage of the microcode scheme is that the size of the SCRIPT can be=
 used as a proxy for CPU load ---- just as it is done for current Bitcoin S=
CRIPT.<br>
As long as the number of `UOP_` micro-opcodes that an `OP_` code can expand=
 to is bounded, and we avoid looping constructs, then the CPU load is also =
bounded and the size of the SCRIPT approximates the amount of processing ne=
eded, thus microcode does not require a softfork to modify weight calculati=
ons in the future.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div></div>

--00000000000097ca2b05dad11afc--