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
Precedence: list

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