diff options
author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2022-11-04 23:07:56 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-11-04 23:08:05 +0000 |
commit | 63bda2f37e6f053875d84b2dbb039bc9ce60b41d (patch) | |
tree | 5cfdff301aa14e2289ee3142785bd53dab24647b | |
parent | c423a9b07889bbe1043e3a566dca893be56968f7 (diff) | |
download | pi-bitcoindev-63bda2f37e6f053875d84b2dbb039bc9ce60b41d.tar.gz pi-bitcoindev-63bda2f37e6f053875d84b2dbb039bc9ce60b41d.zip |
Re: [bitcoin-dev] Validity Rollups on Bitcoin
-rw-r--r-- | 13/787afabd25b10694d9ffd2d300dce37eff7802 | 132 |
1 files changed, 132 insertions, 0 deletions
diff --git a/13/787afabd25b10694d9ffd2d300dce37eff7802 b/13/787afabd25b10694d9ffd2d300dce37eff7802 new file mode 100644 index 000000000..eead66010 --- /dev/null +++ b/13/787afabd25b10694d9ffd2d300dce37eff7802 @@ -0,0 +1,132 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 970B6C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <trey.delbonis@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <ifQPuaXwfXmFtiJrak3aOvpXG8fzm3-eNDCJVS_Us6WI-gcrd4vGeV6ZGk5sKDoy4SEz2K1PSMcVpflRXUmvud1gpVWWDgQr26e-1U5XJ5k=@protonmail.com> +In-Reply-To: <629da3d8-ee34-9acb-511b-4af1913eceff@protonmail.com> +References: <689ed481-e7eb-4fea-8ca7-578503f3f285@app.fastmail.com> + <CAB3F3Dt5oy93duGvYb7SZ7wn7DCvn9FjVwRU9ENNa79yjzmdCQ@mail.gmail.com> + <224cf2f4-2577-4331-9977-ea71e9723ffe@app.fastmail.com> + <WJ0jiInq_I_IiiT8EiAZZN6axo2pSIRCxQWfyvgU-4rjRmeHnCXFNGWFSXoeOv7nVmqoAPr6EHeXRgc-1DfiPX3C8xHwdYzs2qn4Lck06fs=@protonmail.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 <bitcoin-dev@lightco.in> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + |