Date: Tue, 22 Mar 2022 16:22:55 +0000
To: Russell O'Connor <roconnor@blockstream.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <e4r4E0AYzZzkVQp67yxIG-fBBBH8rNrl-MtM7kJXoAsDT_bBSt6gXs_ukw6bBL4845s0OPkrIRjIk54hkQP_pL8X4A--1GFtYcGAl2bW_gs=@protonmail.com>
In-Reply-To: <CAMZUoK=TzOFfMFwNw6gjHtu2EeEPhyL9AjqLS-T=wphc905_JA@mail.gmail.com>
References: <NGFW5p2Gl4t6AqL2E29THMT5DbppMJlB6bdUE6nxAdMajxeFcoRNdt5axNLql08EoyIMsBgZHHHYt_MiITZwzyGZIz0iFX4vaKIYrVV2QhU=@protonmail.com>
 <CAMZUoK=TzOFfMFwNw6gjHtu2EeEPhyL9AjqLS-T=wphc905_JA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets
	Without Softforks
Precedence: list

Good morning Russell,

> Setting aside my thoughts that something like Simplicity would make a bet=
ter platform than Bitcoin Script (due to expression operating on a more nar=
row 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 red=
efined by an OP_RETURN transaction, subsequent transactions of that opcode =
refer to the new microtransaction.=C2=A0 But then we have a race condition =
between people submitting transactions expecting the outputs to refer to th=
e old code and having their code redefined by the time they do get confirme=
d=C2=A0 (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 th=
e 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 mic=
rocode 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 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.


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

Regards,
ZmnSCPxj