path: root/5c/caf9bf1a95ba8c6bb359bc9012526b4267284b

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 77630C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAMhCMoFYF+9NL1sqKfn=ma3C_mfQv7mj2fqbqO5WXVwd6vyhLw@mail.gmail.com>
In-Reply-To: <CAMhCMoFYF+9NL1sqKfn=ma3C_mfQv7mj2fqbqO5WXVwd6vyhLw@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 14 Aug 2023 04:00:57 +0100
Message-ID: <CALZpt+F251k7gSpogwFYHxFtGxc_tZjB4UU4SVEr=WvrsyMVMQ@mail.gmail.com>
To: Salvatore Ingala <salvatore.ingala@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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, <index> 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, <data> 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:
>
>   <data>, <index>, <pk>, <taptree>, <flags>
>
> The core logic of the opcode is as follows:
>
> "Check if the <index>-th input/output's scriptPubKey is a P2TR
> whose public key is obtained from <pk>, (optionally) tweaked with
> <data>, (optionally) tap-tweaked with <taptree>".
>
> The following are special values of the parameters:
>
> - if <pk> is empty, it is replaced with a fixed NUMS point. [**]
> - if <pk> is -1, it is replaced with the current input's taproot
>   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
>   of the taproot merkle tree.
>
> There are two defined flags:
> - CCV_FLAG_CHECK_INPUT =3D 1: if present, <index> 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 <index>-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

<div dir=3D"ltr">Hi Salvatore,<div><br></div><div><span class=3D"gmail-Appl=
e-converted-space">&gt;=C2=A0</span>This also allows inspection of other in=
puts, that was not possible=C2=A0with the original opcodes.<br></div><div><=
br></div><div>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&quot; 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.</div><div><br></div><div>See <a href=3D"https://blog.bitme=
x.com/txwithhold-smart-contracts/">https://blog.bitmex.com/txwithhold-smart=
-contracts/</a> and=C2=A0<a href=3D"https://lists.linuxfoundation.org/piper=
mail/bitcoin-dev/2023-February/021395.html">https://lists.linuxfoundation.o=
rg/pipermail/bitcoin-dev/2023-February/021395.html</a></div><div><br></div>=
<div>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.</div><div><br></div><div>I think this =
is a common risk to all second-layers vaults, lightning channels and paymen=
t pools.</div><div><br></div><div>&gt; A flag can disable this behavior&quo=
t;</div><div><br></div><div>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><div><a href=3D"https://lists.linuxfoundation.=
org/pipermail/bitcoin-dev/2021-July/019243.html">https://lists.linuxfoundat=
ion.org/pipermail/bitcoin-dev/2021-July/019243.html</a><br></div><div><br><=
/div><div>&gt; There are two defined flags:<br>&gt; - CCV_FLAG_CHECK_INPUT =
=3D 1: if present, &lt;index&gt; refers to an input;<br>&gt; =C2=A0otherwis=
e, it refers to an output.<br>&gt; - CCV_FLAG_IGNORE_OUTPUT_AMOUNT =3D 2: o=
nly defined when _CHECK_INPUT<br>&gt; =C2=A0is absent, it disables the defe=
rred checks logic for amounts.<br></div><div><br></div><div>Or even beyond =
a matrix, it could be a set of &quot;tags&quot;. 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.</div><div><br></div><div>&gt; After =
the evaluation of all inputs, it is verified that each output&#39;s<br>&gt;=
 amount is greater than or equal to the total amount in the bucket<br>&gt; =
if that output (validation of the deferred checks).<br></div><div><br></div=
><div>At the very least, I think for the payment pool, where you&#39;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.</div><div><br></div><div>=
&gt; It is unclear if all the special values above will be useful in<br></d=
iv><div>&gt; applications; however, as each special case requires very litt=
le added<br>&gt; code, I tried to make the specs as flexible as possible at=
 this time.<br></div><div><br></div><div>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&#39;s efficient in terms of witness space consumed.</d=
iv><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks =
for the proposal,</div><div><br></div><div>Best,</div><div>Antoine</div><di=
v><br></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">Le=C2=A0dim. 30 juil. 2023 =C3=A0=C2=A022:52, Sa=
lvatore Ingala via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=
=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div><div>Hi all,<b=
r><br>I have put together a first complete proposal for the core opcodes of=
<br>MATT [1][2].<br>The changes make the opcode functionally complete, and =
the<br>implementation is revised and improved.<br><br>The code is implement=
ed in the following fork of the</div><div>bitcoin-inquisition repo:<br><br>=
<a href=3D"https://github.com/Merkleize/bitcoin/tree/checkcontractverify" t=
arget=3D"_blank">https://github.com/Merkleize/bitcoin/tree/checkcontractver=
ify</a><br><br>Therefore, it also includes OP_CHECKTEMPLATEVERIFY, as in a<=
br>previous early demo for vaults [3].<br><br>Please check out the diff [4]=
 if you are interested in the<br>implementation details. It includes some b=
asic functional tests for<br>the main cases of the opcode.<br><br>## Change=
s vs the previous draft<br><br>These are the changes compared to the initia=
l incomplete proposal:<br>- OP_CHECK{IN,OUT}CONTRACTVERIFY are replaced by =
a single opcode<br>=C2=A0 OP_CHECKCONTRACTVERIFY (CCV). An additional `flag=
s` parameter allows<br>=C2=A0 to specify if the opcode operates on an input=
 or an output.<br>=C2=A0 This also allows inspection of other inputs, that =
was not possible<br>=C2=A0 with the original opcodes.<br>- For outputs, the=
 default behavior is to have the following deferred<br>=C2=A0 checks mechan=
ism for amounts: all the inputs that have a CCV towards<br>=C2=A0 the same =
output, have their input amounts summed, and that act as a<br>=C2=A0 lower =
bound for that output&#39;s amount.<br>=C2=A0 A flag can disable this behav=
ior. [*]<br>- A number of special values of the parameters were defined in =
order<br>=C2=A0 to optimize for common cases, and add some implicit introsp=
ection.<br>- The order of parameters is modified (particularly, &lt;data&gt=
; is at the<br>=C2=A0 bottom of the arguments, as so is more natural when w=
riting Scripts).<br><br>## Semantics<br><br>The new OP_CHECKCONTRACTVERIFY =
takes 5 parameters from the stack:<br><br>=C2=A0 &lt;data&gt;, &lt;index&gt=
;, &lt;pk&gt;, &lt;taptree&gt;, &lt;flags&gt;<br><br>The core logic of the =
opcode is as follows:<br><br>&quot;Check if the &lt;index&gt;-th input/outp=
ut&#39;s scriptPubKey is a P2TR<br>whose public key is obtained from &lt;pk=
&gt;, (optionally) tweaked with<br>&lt;data&gt;, (optionally) tap-tweaked w=
ith &lt;taptree&gt;&quot;.<br><br>The following are special values of the p=
arameters:<br><br>- if &lt;pk&gt; is empty, it is replaced with a fixed NUM=
S point. [**]<br>- if &lt;pk&gt; is -1, it is replaced with the current inp=
ut&#39;s taproot<br>=C2=A0 internal key.<br>- if &lt;index&gt; is -1, it is=
 replaced with the current input&#39;s index.<br>- if &lt;data&gt; is empty=
, the data tweak is skipped.<br>- if &lt;taptree&gt; is empty, the taptweak=
 is skipped.<br>- if &lt;taptree&gt; is -1, it is replaced with the current=
 input&#39;s root<br>=C2=A0 of the taproot merkle tree.<br><br>There are tw=
o defined flags:<br>- CCV_FLAG_CHECK_INPUT =3D 1: if present, &lt;index&gt;=
 refers to an input;<br>=C2=A0 otherwise, it refers to an output.<br>- CCV_=
FLAG_IGNORE_OUTPUT_AMOUNT =3D 2: only defined when _CHECK_INPUT<br>=C2=A0 i=
s absent, it disables the deferred checks logic for amounts.<br><br>Finally=
, if both the flags CCV_FLAG_CHECK_INPUT and<br>CCV_FLAG_IGNORE_OUTPUT_AMOU=
NT are absent:<br>=C2=A0 - Add the current input&#39;s amount to the &lt;in=
dex&gt;-th output&#39;s bucket.<br><br>After the evaluation of all inputs, =
it is verified that each output&#39;s<br>amount is greater than or equal to=
 the total amount in the bucket<br>if that output (validation of the deferr=
ed checks).<br><br>## Comment<br><br>It is unclear if all the special value=
s above will be useful in<br>applications; however, as each special case re=
quires very little added<br>code, I tried to make the specs as flexible as =
possible at this time.<br><br>With this new opcode, the full generality of =
MATT (including the fraud<br>proofs) can be obtained with just two opcodes:=
 OP_CHECKCONTRACTVERIFY<br>and OP_CAT.<br>However, additional opcodes (and =
additional introspection) would<br>surely benefit some applications.<br><br=
>I look forward to your comments, and to start drafting a BIP proposal.</di=
v><div><br>Best,<br>Salvatore Ingala<br><br><br>[*] - Credits go to James O=
&#39;Beirne for this approach, taken from his<br>=C2=A0 =C2=A0 =C2=A0 OP_VA=
ULT proposal. I cherry-picked the commit containing the<br>=C2=A0 =C2=A0 =
=C2=A0 Deferred Checks framework.<br>[**] - The same NUMS point suggested i=
n BIP-0341 was used.<br><br><br>References:<br><br>[1] - <a href=3D"https:/=
/merkle.fun/" target=3D"_blank">https://merkle.fun/</a><br>[2] - <a href=3D=
"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/0211=
82.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitc=
oin-dev/2022-November/021182.html</a><br>[3] - <a href=3D"https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html" target=3D"_b=
lank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/02=
1588.html</a><br>[4] -=C2=A0<a href=3D"https://github.com/bitcoin-inquisiti=
on/bitcoin/compare/24.0...Merkleize:bitcoin:checkcontractverify" target=3D"=
_blank">https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Merkl=
eize:bitcoin:checkcontractverify</a><br></div></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000002ac2fe0602d94632--