summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorZmnSCPxj <ZmnSCPxj@protonmail.com>2022-11-04 23:07:56 +0000
committerbitcoindev <bitcoindev@gnusha.org>2022-11-04 23:08:05 +0000
commit63bda2f37e6f053875d84b2dbb039bc9ce60b41d (patch)
tree5cfdff301aa14e2289ee3142785bd53dab24647b
parentc423a9b07889bbe1043e3a566dca893be56968f7 (diff)
downloadpi-bitcoindev-63bda2f37e6f053875d84b2dbb039bc9ce60b41d.tar.gz
pi-bitcoindev-63bda2f37e6f053875d84b2dbb039bc9ce60b41d.zip
Re: [bitcoin-dev] Validity Rollups on Bitcoin
-rw-r--r--13/787afabd25b10694d9ffd2d300dce37eff7802132
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
+