Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8806CC000B for ; Tue, 22 Mar 2022 16:23:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 735B360E34 for ; Tue, 22 Mar 2022 16:23:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42RTY6VVbUB3 for ; Tue, 22 Mar 2022 16:23:03 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25]) by smtp3.osuosl.org (Postfix) with ESMTPS id 4691260A9C for ; Tue, 22 Mar 2022 16:23:03 +0000 (UTC) Date: Tue, 22 Mar 2022 16:22:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1647966180; bh=1oRXL8HF10wyRxKveefMruVrtSmHRFJYLqmHKpUWSBs=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=BAXPz6fYzE/EayqCSM8RTV/7AAUzfJ50c2AYsr+VYHoDipPRjh1Z+bAub5NejtGJA bgW5qZ27rYQzzQG459wVgkWduAPeGlF//B4NjXXkj1EoNH9sHZls3s5limUjuwUfv+ W/+85hZQP/fyeO3VOANvhrCaVIzR6Qc+Z23y6wuBboAx/flG5UGIqfBRwho0NWJOhH xuYoh8ylW5vDb4gWhEzGLIXrHs+3eEVW9dIwNhe7aPzVQBpma17ICx3dnZQ63GgkC8 TUhnUi4KX9TWh04BvGacdlUfYBjSS2f+FVdKEUnWQ+zC0g5XJvtiiKBsJeN9gW+Yqd SqZ4ANqdukczQ== To: Russell O'Connor From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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:23:04 -0000 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