Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3A7B9C002D for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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