From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 970B6C002D for ; Fri, 4 Nov 2022 23:08:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6530B4014D for ; Fri, 4 Nov 2022 23:08:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6530B4014D Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=wvjPfg7I X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 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_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xac99qJBye56 for ; Fri, 4 Nov 2022 23:08:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 95873400FD Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) by smtp2.osuosl.org (Postfix) with ESMTPS id 95873400FD for ; Fri, 4 Nov 2022 23:08:04 +0000 (UTC) Date: Fri, 04 Nov 2022 23:07:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1667603281; x=1667862481; bh=aL/OvFUm9diqO7WNvw7A2Y7PdovXFm5OlSJ0fH+W48s=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=wvjPfg7IU8+aSHTXdFqM9/FR2bDrF+MZQif6Yn+02h/Kf4UV+NPV+Ecl5X/vOta5g cCqwMUUw4cEzI9fqKtTDiXlsSEnSg6ALPc4wcW2+53xhU+q3NaDTI/L+uG1sSsh4ta gkV2KuiiD8Ef3znwACFlv0SmvsM67pc0hznvcZckc/CbqwAj22+meslsSiA2qnktCb T/N9lJQ2PPy8gY2ah4/8yKHM//vvdjzhvU08eoiVruF/ZVo/2kkMIb+5dXwq2mKJjC LRPFxfhR+qPggBY5ZLp3UvR2OA+xdD3Q3HrEWeDiXHajDxoQ0OX+R9kNmosr64XFgg dAkgEnhr3qzTQ== To: Trey Del Bonis , Bitcoin Protocol Discussion From: ZmnSCPxj Message-ID: In-Reply-To: <629da3d8-ee34-9acb-511b-4af1913eceff@protonmail.com> References: <689ed481-e7eb-4fea-8ca7-578503f3f285@app.fastmail.com> <224cf2f4-2577-4331-9977-ea71e9723ffe@app.fastmail.com> <629da3d8-ee34-9acb-511b-4af1913eceff@protonmail.com> Feedback-ID: 2872618:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: John Light Subject: Re: [bitcoin-dev] Validity Rollups on Bitcoin 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: Fri, 04 Nov 2022 23:08:05 -0000 Good morning Trey, > * something like OP_PUSHSCRIPT which would remove the need for the > introspection the the prevout's script and avoids duplicating data in > the witness > * some kind of OP_MERKLEUPDATEVERIFY which checks a merkle proof for a > leaf against a root and checks if replacing the leaf with some hash > using the proof yields a specified updated root (or instead, a version > that just pushes the updated root) > * if we really wanted to golf the size of the script, then possibly a > limited form of OP_EVAL if we can't figure out another way to split up > the different spend paths into different tapleafs while still being able > to do the recursive covenant, but still the script and the vk would > still be significant so it's not actually that much benefit per-batch A thing I had been musing on is to reuse pay-to-contract to store a commitm= ent to the state. As we all know, in Taproot, the Taproot outpoint script is just the public = key corresponding to the pay-to-contract of the Taproot MAST root and an in= ternal public key. The internal public key can itself be a pay-to-contract, where the contract= being committed to would be the state of some covenant. One could then make an opcode which is given an "internal internal" pubkey = (i.e. the pubkey that is behind the pay-to-contract to the covenant state, = which when combined serves as the internal pubkey for the Taproot construct= ), a current state, and an optional expected new state. It determines if the Taproot internal pubkey is actually a pay-to-contract = of the current state on the internal-internal pubkey. If the optional expected new state exists, then it also recomputes a pay-to= -contract of the new state to the same internal-internal pubkey, which is a= new Taproot internal pubkey, and then recomputes a pay-to-contract of the = same Taproot MAST root on the new Taproot internal pubkey, and that the fir= st output commits to that. Basically it retains the same MASTed set of Tapscripts and the same interna= l-internal pubkey (which can be used to escape the covenant, in case a bug = is found, if it is an n-of-n of all the interested parties, or otherwise sh= ould be a NUMS point if you trust the tapscripts are bug-free), only modify= ing the covenant state. The covenant state is committed to on the Taproot output, indirectly by two= nested pay-to-contracts. With this, there is no need for quining and `OP_PUSHSCRIPT`. The mechanism only needs some way to compute the new state from the old sta= te. In addition, you can split up the control script among multiple Tapscript b= ranches and only publish onchain (=3D=3D spend onchain bytes) the one you n= eed for a particular state transition. Regards, ZmnSCPxj