diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2022-11-08 12:01:11 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-11-08 12:01:30 +0000 |
| commit | d771ffb194741259b4ac7202a32d20f57cab3959 (patch) | |
| tree | 9b898303283512b43e7ccebbefafbc76b3edc3c2 | |
| parent | 70c7f1d437920420f4f00482e7a30b0e4c01c4cd (diff) | |
| download | pi-bitcoindev-d771ffb194741259b4ac7202a32d20f57cab3959.tar.gz pi-bitcoindev-d771ffb194741259b4ac7202a32d20f57cab3959.zip | |
Re: [bitcoin-dev] Merkleize All The Things
| -rw-r--r-- | e6/0d310be9b208396c98916786fc2ae60af0613f | 125 |
1 files changed, 125 insertions, 0 deletions
diff --git a/e6/0d310be9b208396c98916786fc2ae60af0613f b/e6/0d310be9b208396c98916786fc2ae60af0613f new file mode 100644 index 000000000..1dc61704a --- /dev/null +++ b/e6/0d310be9b208396c98916786fc2ae60af0613f @@ -0,0 +1,125 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 3A7B9C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 8 Nov 2022 12:01:30 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 0800C402DC + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 8 Nov 2022 12:01:30 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0800C402DC +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=F/AEznat +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 IIOfTjsH2OL7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 8 Nov 2022 12:01:28 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9A48640104 +Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 9A48640104 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 8 Nov 2022 12:01:28 +0000 (UTC) +Date: Tue, 08 Nov 2022 12:01:11 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail3; t=1667908886; x=1668168086; + bh=10vyl1VaZuxaKaJ6kQk4Q+Fa5V36zv6mTuYSKDSbdSg=; + h=Date:To:From:Subject:Message-ID:In-Reply-To:References: + Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: + Message-ID:BIMI-Selector; + b=F/AEznattWwZS3gVx6FY2FpXv3soeLy9wrF5yVv1MW2Al8zLC2i68ZLIFufM6+y+D + 9lVcGLRWw2Zj6aqL82vu7ZSk7//wGN2xFJmbvu3ODPPijmofeDbVBmSUgNpvy3aonB + jFG3SMorn6dUglM1duwkFu79gsKZvLoWzg/rhwdwZskZhcgGAFbOlTF5U3Q3X86roF + B/U8+OEyPF6u58uiYrQbVvr8+VjevBlEO4It9dvbT1k2ucS67j1D2tx0LAHNp2aa/Q + RxDlXfWiG37O6gwzeiHu7ed1Ng2L4SpS/fSF2Iy4+g2XDWjOHhRzUoVtHoBwJds4WQ + Etue47QODwQhA== +To: Salvatore Ingala <salvatore.ingala@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <Vbb1PZfBzm6JBddqNIfikVE2G1fDmObt0BBt2BqhmHV_Tx7KLGU5SSQPPp0OaLZHAKrkKobA2f60tX4TOl996aE9ds1tZWaGAHbSr9wu5r0=@protonmail.com> +In-Reply-To: <CAMhCMoH9uZPeAE_2tWH6rf0RndqV+ypjbNzazpFwFnLUpPsZ7g@mail.gmail.com> +References: <CAMhCMoH9uZPeAE_2tWH6rf0RndqV+ypjbNzazpFwFnLUpPsZ7g@mail.gmail.com> +Feedback-ID: 2872618:user:proton +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +Subject: Re: [bitcoin-dev] Merkleize All The Things +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: Tue, 08 Nov 2022 12:01:30 -0000 + +Good morning Salvatore, + +Interesting idea. + +The idea to embed the current state is similar to something I have been mus= +ing about recently. + + +> ### Game theory (or why the chain will not see any of this) +>=20 +> With the right economic incentives, protocol designers can guarantee that= + playing a losing game always loses money compared to cooperating. Therefor= +e, the challenge game is never expected to be played on-chain. The size of = +the bonds need to be appropriate to disincentivize griefing attacks. + +Modulo bugs, operator error, misconfigurations, and other irrationalities o= +f humans. + + + +> - OP_CHECKOUTPUTCOVENANTVERIFY: given a number out_i and three 32-byte ha= +sh elements x, d and taptree on top of the stack, verifies that the out_i-t= +h output is a P2TR output with internal key computed as above, and tweaked = +with taptree. This is the actual covenant opcode. + +Rather than get taptree from the stack, just use the same taptree as in the= + revelation of the P2TR. +This removes the need to include quining and similar techniques: just do th= +e quining in the SCRIPT interpreter. + +The entire SCRIPT that controls the covenant can be defined as a taptree wi= +th various possible branches as tapleaves. +If the contract is intended to terminate at some point it can have one of t= +he tapleaves use `OP_CHECKINPUTCOVENANTVERIFY` and then determine what the = +output "should" be using e.g. `OP_CHECKTEMPLATEVERIFY`. + + +> - Is it worth adding other introspection opcodes, for example OP_INSPECTV= +ERSION, OP_INSPECTLOCKTIME? See Liquid's Tapscript Opcodes [6]. + +`OP_CHECKTEMPLATEVERIFY` and some kind of sha256 concatenated hashing shoul= +d be sufficient I think. + +> - Is there any malleability issue? Can covenants =E2=80=9Crun=E2=80=9D wi= +thout signatures, or is a signature always to be expected when using spendi= +ng conditions with the covenant encumbrance? That might be useful in contra= +cts where no signature is required to proceed with the protocol (for exampl= +e, any party could feed valid data to the bisection protocol above). + +Hmm protocol designer beware? + +Regards, +ZmnSCPxj + |