From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7B694C0032 for ; Mon, 7 Aug 2023 11:37:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5958840917 for ; Mon, 7 Aug 2023 11:37:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5958840917 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=fDVwjCZi X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 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, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Xlos6k5nksV for ; Mon, 7 Aug 2023 11:37:20 +0000 (UTC) Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) by smtp4.osuosl.org (Postfix) with ESMTPS id C768740218 for ; Mon, 7 Aug 2023 11:37:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C768740218 Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-5860c7fc2fcso44938327b3.2 for ; Mon, 07 Aug 2023 04:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691408238; x=1692013038; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fhcxprRC50yd+2Y03/JRteTGmT30aaL7FQIam4dlHcc=; b=fDVwjCZigGANajPlWLWlZoBR6DN4aDmG491WJanMFiL1+LLD+dTr7HeZF80s5E/LPk HI0hhovr9An5u+NJrble60y0gBs2dpWh4x+HUb2+a+M4IpO5xlZAuSGiDdicAU3rVWmS MhJCQof7CD/7OTi4xhGnLQJbBEbiTynZIX/IJu3IVnPoMVbh2okqWp7C3P6Lv9SQ9Lzu vvhy6B2f3FsN1RdJUuCouFSTeb2xodBd0NwIJC+ZUNV/bWBD1AtIIlYZUXTKGgD6FeLQ 9lGvORY2s1Gtd3IZXOiCqRDX5eXUIzjpFZ+uQ7xGBIvci+eNs+Jp5H6Wtd3X17MhWN98 wT7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691408238; x=1692013038; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fhcxprRC50yd+2Y03/JRteTGmT30aaL7FQIam4dlHcc=; b=RRu1sLCRLB4vlxjjsrqi5cNWyOW9YN1ZIUrv07mdKF3yTjZ22Ublr13weUg9PLHqZI q62obl4ue7wVw1yXQhPupcJUjZFs0MtcMRztLoAHmcW+CWahGv2J42Sa9Tp38muS8qdb la1sZmguLCgKv2VgxVLO0mCKScoJRm8AW8EvA/CdDD7dEJsq7FMlGnXhRvQNndVDTlpU cz46CB9AKu+wBe7RnLHZ6tdV1/aBkwq7l6Y6/a+duW0dqCvneuHGGfWqgGUqgGwN/dlq kfBy6SolbifE4/bVCUtQDZpH8TGy+t9dwTD6L2a4ZAdUOVceH6Xg2kUMesfIiTJYDv33 832Q== X-Gm-Message-State: AOJu0YxVYIPN/lCk3KS1pHAL9E2I6uV8+wPzYrHbiQsO1VGxGqKGBnKy VOUb8CoS/dqb9nvRl9il0Fxb0zqIRr1Y+vmD86KEfZgdSkFrOw== X-Google-Smtp-Source: AGHT+IGERdlVqmNMqTdhSfpMZ4FM71VHaUox1GpEB9GSTZ1NER2v6MFnzMFrxjAKIPVnvScIJVLgBuputUMOJCe2mak= X-Received: by 2002:a25:25d5:0:b0:bfe:e383:6297 with SMTP id l204-20020a2525d5000000b00bfee3836297mr7550650ybl.19.1691408238576; Mon, 07 Aug 2023 04:37:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= Date: Mon, 7 Aug 2023 13:37:07 +0200 Message-ID: To: Salvatore Ingala , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 08 Aug 2023 14:06:48 +0000 Subject: Re: [bitcoin-dev] Concrete MATT opcodes 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: Mon, 07 Aug 2023 11:37:21 -0000 Hi, Salvatore. Thanks for the update! I like the fact that taptree verification now can be done on both input and outputs, and having them be symmetrical also makes the learning curve a bit easier. I have implemented the updated opcodes in btcd (very rough implementation)]1] as well as updated the example scripts for simulating CTV[2] and Coinpools[3]. >From doing this I would again like to offer some suggestions on the proposa= l. - For the opcode parameter ordering, it feels unnatural for the two tweaks (data, taptree) to be separated by the internal key. A more natural ordering of parameters IMO would be (of course this is all subjective): OP_CCV. If you disagree, I would love some rationale for the ordering you chose! (looks like you also changed it again after your last post?). - The deferred amount check seems a bit out of place, and insufficient at least for the use cases I had in mind. They work well in a vault setting, where you want to consolidate many outputs into a single new one, and in 1-input-1-output settings where you want to preserve the amount exactly. However, for coinpools, CTV with more than one output and other interesting contracts where you want to split or combine amounts it won't be powerful enough. I'm wondering what other use cases you had in mind for the deferred output amount check? Maybe I have missed something, but if not it would perhaps be better to leave out the amount preservation check, or go the extra mile and propose a more powerful amount introspection machinery. Cheers, Johan [1] - https://github.com/halseth/btcd/pull/1 [2] - https://github.com/halseth/tapsim/blob/8f4ac4d914fde0847c72cd22bdd45a= 1b7247cadf/examples/matt/ctv2/README.md [3] - https://github.com/halseth/tapsim/blob/8f4ac4d914fde0847c72cd22bdd45a= 1b7247cadf/examples/matt/coinpool/README.md On Sun, Jul 30, 2023 at 11:51=E2=80=AFPM Salvatore Ingala via bitcoin-dev wrote: > > Hi all, > > I have put together a first complete proposal for the core opcodes of > MATT [1][2]. > The changes make the opcode functionally complete, and the > implementation is revised and improved. > > The code is implemented in the following fork of the > bitcoin-inquisition repo: > > https://github.com/Merkleize/bitcoin/tree/checkcontractverify > > Therefore, it also includes OP_CHECKTEMPLATEVERIFY, as in a > previous early demo for vaults [3]. > > Please check out the diff [4] if you are interested in the > implementation details. It includes some basic functional tests for > the main cases of the opcode. > > ## Changes vs the previous draft > > These are the changes compared to the initial incomplete proposal: > - OP_CHECK{IN,OUT}CONTRACTVERIFY are replaced by a single opcode > OP_CHECKCONTRACTVERIFY (CCV). An additional `flags` parameter allows > to specify if the opcode operates on an input or an output. > This also allows inspection of other inputs, that was not possible > with the original opcodes. > - For outputs, the default behavior is to have the following deferred > checks mechanism for amounts: all the inputs that have a CCV towards > the same output, have their input amounts summed, and that act as a > lower bound for that output's amount. > A flag can disable this behavior. [*] > - A number of special values of the parameters were defined in order > to optimize for common cases, and add some implicit introspection. > - The order of parameters is modified (particularly, is at the > bottom of the arguments, as so is more natural when writing Scripts). > > ## Semantics > > The new OP_CHECKCONTRACTVERIFY takes 5 parameters from the stack: > > , , , , > > The core logic of the opcode is as follows: > > "Check if the -th input/output's scriptPubKey is a P2TR > whose public key is obtained from , (optionally) tweaked with > , (optionally) tap-tweaked with ". > > The following are special values of the parameters: > > - if is empty, it is replaced with a fixed NUMS point. [**] > - if is -1, it is replaced with the current input's taproot > internal key. > - if is -1, it is replaced with the current input's index. > - if is empty, the data tweak is skipped. > - if is empty, the taptweak is skipped. > - if is -1, it is replaced with the current input's root > of the taproot merkle tree. > > There are two defined flags: > - CCV_FLAG_CHECK_INPUT =3D 1: if present, refers to an input; > otherwise, it refers to an output. > - CCV_FLAG_IGNORE_OUTPUT_AMOUNT =3D 2: only defined when _CHECK_INPUT > is absent, it disables the deferred checks logic for amounts. > > Finally, if both the flags CCV_FLAG_CHECK_INPUT and > CCV_FLAG_IGNORE_OUTPUT_AMOUNT are absent: > - Add the current input's amount to the -th output's bucket. > > After the evaluation of all inputs, it is verified that each output's > amount is greater than or equal to the total amount in the bucket > if that output (validation of the deferred checks). > > ## Comment > > It is unclear if all the special values above will be useful in > applications; however, as each special case requires very little added > code, I tried to make the specs as flexible as possible at this time. > > With this new opcode, the full generality of MATT (including the fraud > proofs) can be obtained with just two opcodes: OP_CHECKCONTRACTVERIFY > and OP_CAT. > However, additional opcodes (and additional introspection) would > surely benefit some applications. > > I look forward to your comments, and to start drafting a BIP proposal. > > Best, > Salvatore Ingala > > > [*] - Credits go to James O'Beirne for this approach, taken from his > OP_VAULT proposal. I cherry-picked the commit containing the > Deferred Checks framework. > [**] - The same NUMS point suggested in BIP-0341 was used. > > > References: > > [1] - https://merkle.fun/ > [2] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Novemb= er/021182.html > [3] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/= 021588.html > [4] - https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Merkl= eize:bitcoin:checkcontractverify > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev