From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 04801C000B for ; 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 ; 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 ; 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 ; Tue, 22 Mar 2022 16:28:33 +0000 (UTC) Received: by mail-qv1-xf31.google.com with SMTP id ke15so5132862qvb.11 for ; 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: In-Reply-To: From: "Russell O'Connor" Date: Tue, 22 Mar 2022 12:28:21 -0400 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="00000000000097ca2b05dad11afc" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Thanks for the clarification.

You don't think referring to the microcode via its hash, effectiv= ely 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)) t= here 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 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).

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