Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 77630C0032 for ; Mon, 14 Aug 2023 03:01:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 516E9408CA for ; Mon, 14 Aug 2023 03:01:11 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 516E9408CA Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=VA0vyarL X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 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, HTML_MESSAGE=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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbDIhGW74_q7 for ; Mon, 14 Aug 2023 03:01:10 +0000 (UTC) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by smtp2.osuosl.org (Postfix) with ESMTPS id C722040121 for ; Mon, 14 Aug 2023 03:01:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C722040121 Received: by mail-io1-xd34.google.com with SMTP id ca18e2360f4ac-790b95beeedso193106639f.0 for ; Sun, 13 Aug 2023 20:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691982069; x=1692586869; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=sXdTPc4hCeO1pcLQgfiQeVbD6SGZFvf9iz7LoTB3u9o=; b=VA0vyarLvAevo7Oz12EvrM8hdVSwsN0kMr4ifQcvc+hCC/PUnP47dXub4diWCZg7Xt VOP1oBQH0ox3XqHutXvmrNzF8piclwxETLi4DKOUgXyPLRwwOEsE2yUqqUFKR1IjfKkt O6HfmW4tcQz4m2nLLzVId6S8DydGRpGDlWX1b8Snl9zxGhrNGHAKtEXOlqAgd7fQfnnS S3t/wQDiIXFxHp7CevVbbYKSIm6kkLx7bSYWpmAMZrjOE+ID0hN4fzeQ7QhKSn2Aozu/ NyuQ3xEnWPQV/sN5QFOnDwF0I8ervjo680fr5wN88YtiIkZkMM1VR6Cxf2b5oV8ZqB2E 3w8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691982069; x=1692586869; h=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=sXdTPc4hCeO1pcLQgfiQeVbD6SGZFvf9iz7LoTB3u9o=; b=MIgmsQNvbXhjSZR13oTP9nhRj1xG2mS8rYQrclznRFQhxYtNUq2q6WS7mXTwH9UjrB uXbwD9PbQlZ2gHjnqb6z2zDLEhj50ICZOv5EF6sGNHjhtx0IUjTHOqMsXji0LuavQdKB RqIkRE4WfBl8VLRcHZbvXAJOBkg1xZ155HxFpVJdFg3PuVbmhka/z/Jse9BEWQlxZxF2 nWpGqptzaauy7fU6IikyzYkW6g1ZsDLAKTyFu4fuCZPr2iCVzBi3D9haLgQ3RO1+xcqG G5z0CC76A31GOmL0FJRRcill1QVfEbmj68yevf7IBgfQsQvlBRUslmdYXRFMeCJAPnud h1lA== X-Gm-Message-State: AOJu0Yz3cNpnfm3o9HfqSyV1OMn3utmDgHt5uZbZNkBqkBbrbcmMXa33 l8VHuIpC3DaF0dYiLjM4JF/x0006icr88hk8RaQ= X-Google-Smtp-Source: AGHT+IGV5m96CbAO1oU0MrTumLdaZlRX6Et5UZBClB8uVqf63Z1ylyS8bQOyauEWj2vymZoavoGTBdDN/FHHcKZyl20= X-Received: by 2002:a05:6e02:1be1:b0:346:50ce:d602 with SMTP id y1-20020a056e021be100b0034650ced602mr15451177ilv.1.1691982068628; Sun, 13 Aug 2023 20:01:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Mon, 14 Aug 2023 04:00:57 +0100 Message-ID: To: Salvatore Ingala , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000002ac2fe0602d94632" X-Mailman-Approved-At: Mon, 14 Aug 2023 07:01:22 +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, 14 Aug 2023 03:01:11 -0000 --0000000000002ac2fe0602d94632 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Salvatore, > This also allows inspection of other inputs, that was not possible with the original opcodes. I think cross-input inspection (not cross-input signature aggregation which is different) is opening a pandora box in terms of "malicious" off-chain contracts than one could design. E.g miners bribing contracts to censor the confirmation of time-sensitive lightning channel transactions, where the bribes are paid on the hashrate distribution of miners during the previous difficulty period, thanks to the coinbase pubkey. See https://blog.bitmex.com/txwithhold-smart-contracts/ and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/02139= 5.html I wonder if we might face the dilemma of miners censorship attacks, if we wish to have more advanced bitcoin contracts, though I think it would be safe design practice to rule out those types of concerns thanks to smart bitcoin contracting primitives. I think this is a common risk to all second-layers vaults, lightning channels and payment pools. > A flag can disable this behavior" More than a binary flag like a matrix could be introduced to encode subset of introspected inputs /outputs to enable sighash_group-like semantic: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.ht= ml > 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. Or even beyond a matrix, it could be a set of "tags". There could be a generalized tag for unstructured data, and another one for bitcoin transaction / script data types (e.g scriptpubkey, amount, nsequence, merkle branch) that could be fetched from the taproot annex. > 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). At the very least, I think for the payment pool, where you're fanning-out satoshis value from a subset of inputs to another subset of outputs, I think you would need more malleability here. > 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. I think this generic framework is interesting for joinpool / coinpool / payment pool, as you can check that any withdrawal output can be committed as part of the input scriptpubkey, and spend it on blessed-with-one-participant-sig script. There is still a big open question if it's efficient in terms of witness space consumed. That said, I still think you would need at least ANYPREVOUT and more malleability for the amount transfer validation as laid out above. Looking on the `DeferredCheck` framework commit, one obvious low-level concern is the DoS risk for full-nodes participating in transaction-relay, and that maybe policy rules should be introduced to keep the worst-CPU input in the ranges of current transaction spend allowed to propagate on the network today. Thanks for the proposal, Best, Antoine Le dim. 30 juil. 2023 =C3=A0 22:52, Salvatore Ingala via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > 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-November/021= 182.html > [3] - > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588= .html > [4] - > https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Merkleize:b= itcoin:checkcontractverify > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000002ac2fe0602d94632 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Salvatore,

>=C2=A0This also allows inspection of other in= puts, that was not possible=C2=A0with the original opcodes.
<= br>
I think cross-input inspection (not cross-input signature agg= regation=C2=A0which is different) is opening a pandora box in terms of &quo= t;malicious" off-chain contracts than one could design. E.g miners bri= bing contracts to censor the confirmation of time-sensitive lightning=C2=A0= channel transactions, where the bribes=C2=A0are paid on the hashrate=C2=A0d= istribution of miners during the previous difficulty period, thanks to the = coinbase pubkey.


=
I wonder if we might face the dilemma=C2=A0of miners censorship attack= s, if we wish to have more advanced bitcoin contracts, though I think it wo= uld be safe design practice to rule out those types of concerns thanks to s= mart bitcoin contracting primitives.

I think this = is a common risk to all second-layers vaults, lightning channels and paymen= t pools.

> A flag can disable this behavior&quo= t;

More than a binary flag like a matrix could be = introduced to encode subset of introspected inputs /outputs to enable sigha= sh_group-like semantic:

<= /div>
> There are two defined flags:
> - CCV_FLAG_CHECK_INPUT = =3D 1: if present, <index> refers to an input;
> =C2=A0otherwis= e, it refers to an output.
> - CCV_FLAG_IGNORE_OUTPUT_AMOUNT =3D 2: o= nly defined when _CHECK_INPUT
> =C2=A0is absent, it disables the defe= rred checks logic for amounts.

Or even beyond = a matrix, it could be a set of "tags". There could be a generaliz= ed tag for unstructured data, and another one for bitcoin transaction / scr= ipt data types (e.g scriptpubkey, amount, nsequence, merkle branch) that co= uld be fetched from the taproot annex.

> 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).

At the very least, I think for the payment pool, where you're fan= ning-out satoshis value from a subset of inputs to another subset of output= s, I think you would need more malleability here.

= > It is unclear if all the special values above will be useful in
> applications; however, as each special case requires very litt= le added
> code, I tried to make the specs as flexible as possible at= this time.

I think this generic framework is = interesting for joinpool / coinpool / payment pool, as you can check that a= ny withdrawal output can be committed as part of the input scriptpubkey, an= d spend it on blessed-with-one-participant-sig script. There is still a big= open question if it's efficient in terms of witness space consumed.

That said, I still think you would need at least ANY= PREVOUT and more malleability for the amount transfer validation as laid ou= t above.

Looking on the `DeferredCheck` framework = commit, one obvious low-level concern is the DoS risk for full-nodes partic= ipating in transaction-relay, and that maybe policy rules should be introdu= ced to keep the worst-CPU input in the ranges of current transaction spend = allowed to propagate on the network today.

Thanks = for the proposal,

Best,
Antoine



Le=C2=A0dim. 30 juil. 2023 =C3=A0=C2=A022:52, Sa= lvatore Ingala via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit= =C2=A0:
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 implement= ed in the following fork of the
bitcoin-inquisition repo:

= https://github.com/Merkleize/bitcoin/tree/checkcontractver= ify

Therefore, it also includes OP_CHECKTEMPLATEVERIFY, as in a<= br>previous early demo for vaults [3].

Please check out the diff [4]= if you are interested in the
implementation details. It includes some b= asic functional tests for
the main cases of the opcode.

## Change= s vs the previous draft

These are the changes compared to the initia= l incomplete proposal:
- OP_CHECK{IN,OUT}CONTRACTVERIFY are replaced by = a single opcode
=C2=A0 OP_CHECKCONTRACTVERIFY (CCV). An additional `flag= s` parameter allows
=C2=A0 to specify if the opcode operates on an input= or an output.
=C2=A0 This also allows inspection of other inputs, that = was not possible
=C2=A0 with the original opcodes.
- For outputs, the= default behavior is to have the following deferred
=C2=A0 checks mechan= ism for amounts: all the inputs that have a CCV towards
=C2=A0 the same = output, have their input amounts summed, and that act as a
=C2=A0 lower = bound for that output's amount.
=C2=A0 A flag can disable this behav= ior. [*]
- A number of special values of the parameters were defined in = order
=C2=A0 to optimize for common cases, and add some implicit introsp= ection.
- The order of parameters is modified (particularly, <data>= ; is at the
=C2=A0 bottom of the arguments, as so is more natural when w= riting Scripts).

## Semantics

The new OP_CHECKCONTRACTVERIFY = takes 5 parameters from the stack:

=C2=A0 <data>, <index>= ;, <pk>, <taptree>, <flags>

The core logic of the = opcode is as follows:

"Check if the <index>-th input/outp= ut's scriptPubKey is a P2TR
whose public key is obtained from <pk= >, (optionally) tweaked with
<data>, (optionally) tap-tweaked w= ith <taptree>".

The following are special values of the p= arameters:

- if <pk> is empty, it is replaced with a fixed NUM= S point. [**]
- if <pk> is -1, it is replaced with the current inp= ut's taproot
=C2=A0 internal key.
- if <index> is -1, it is= replaced with the current input's index.
- if <data> is empty= , the data tweak is skipped.
- if <taptree> is empty, the taptweak= is skipped.
- if <taptree> is -1, it is replaced with the current= input's root
=C2=A0 of the taproot merkle tree.

There are tw= o defined flags:
- CCV_FLAG_CHECK_INPUT =3D 1: if present, <index>= refers to an input;
=C2=A0 otherwise, it refers to an output.
- CCV_= FLAG_IGNORE_OUTPUT_AMOUNT =3D 2: only defined when _CHECK_INPUT
=C2=A0 i= s absent, it disables the deferred checks logic for amounts.

Finally= , if both the flags CCV_FLAG_CHECK_INPUT and
CCV_FLAG_IGNORE_OUTPUT_AMOU= NT are absent:
=C2=A0 - Add the current input's amount to the <in= dex>-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 deferr= ed checks).

## Comment

It is unclear if all the special value= s above will be useful in
applications; however, as each special case re= quires 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
=C2=A0 =C2=A0 =C2=A0 OP_VA= ULT proposal. I cherry-picked the commit containing the
=C2=A0 =C2=A0 = =C2=A0 Deferred Checks framework.
[**] - The same NUMS point suggested i= n BIP-0341 was used.


References:

[1] - https://merkle.fun/
[2] - https://lists.linuxfoundation.org/pipermail/bitc= oin-dev/2022-November/021182.html
[3] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/02= 1588.html
[4] -=C2=A0https://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/mail= man/listinfo/bitcoin-dev
--0000000000002ac2fe0602d94632--