Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9E24BC0032 for ; Fri, 18 Aug 2023 20:12:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 74216615EF for ; Fri, 18 Aug 2023 20:12:23 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 74216615EF Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=MbuNJBq6 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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f73eD_2H1oip for ; Fri, 18 Aug 2023 20:12:21 +0000 (UTC) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by smtp3.osuosl.org (Postfix) with ESMTPS id 572E0615EE for ; Fri, 18 Aug 2023 20:12:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 572E0615EE Received: by mail-io1-xd34.google.com with SMTP id ca18e2360f4ac-790b95beeedso45781839f.0 for ; Fri, 18 Aug 2023 13:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692389540; x=1692994340; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GcF88Qqre87FJpPlDE4AKGSQXsaizccK2v4Q6kztMoc=; b=MbuNJBq6qDAeHtIY31M+kkhESkIrQmLmHVOX95jPUMBP5rHM5NZhlMvgjo7Rlrxp7K MQWafMgxIHyXPxG1LRtOa/bTruUnEuKR7B4vaGD909mggFVx5paXgBJWlnNIm47/Zmhz lKqjfTHz3rkiHGe3Ly3e5P7majUvjWZ51fVJ0OtpxeaQHpce3aVL7W29EunaEWOU+hpf rXi/cPJzHXvtcGYfGPTC8Fq4vXksh+srpS4O3vgN78HCp/uCFr/B+jUuShhqhCgkUwMd XUT35rvSGMvJkLM4QgSthcGiNSIKuLwsxi73DITEXcjGDUEztLWJwVoa4KCt3jP/7zZN MPiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692389540; x=1692994340; h=cc: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=GcF88Qqre87FJpPlDE4AKGSQXsaizccK2v4Q6kztMoc=; b=BlOz7aXngzjtQuMLIkfT2B8jj7kcYH09oZvmTMH6zmR9oVMwFhCL3BUbvZoC3I7RjD LTPYaorL43c8J3QTSx5LCRw1CgKDzdwjxhhewV5XEC1sjE7uORl2I+onFIVEWGaLFxIu wDx3tivzN2sg6GDIXB0Ke392wtonvvqTw2xuWfPCCL+V3+rVV3hi0478PAhdE2rvg6Dp zgrlEzfZxaFZPnSedrz4pKvNXddea9MWo2aAaYO0wLURvO5u0IDXE1z90f9qy8InfuoG V7rXoH7c1NKPt4HHuZrVK2bPZwrSRA+yRr18DHliNDkKpYiW1nFXdd2jmwVlxGgZ/exd sDPA== X-Gm-Message-State: AOJu0YwdnKfN4jT013uQTrwZFiTciamkR/Lt4+KbEAXMlbbhwN0AF5Je cogXgcXAWbk+t2MelgGGqtTds3s5XZyCVaLX/1w= X-Google-Smtp-Source: AGHT+IH4wWZcBYpTy2eOnI175cT29/dGZrd92mUn2Qr2kKrS/bNQL90/ryX960eV7SYkXop5RulpYAzqVhy5j+S9Zbg= X-Received: by 2002:a5e:a707:0:b0:780:c787:637b with SMTP id b7-20020a5ea707000000b00780c787637bmr367511iod.0.1692389540192; Fri, 18 Aug 2023 13:12:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Fri, 18 Aug 2023 21:12:09 +0100 Message-ID: To: symphonicbtc Content-Type: multipart/alternative; boundary="0000000000005d67750603382589" X-Mailman-Approved-At: Sat, 19 Aug 2023 13:03:39 +0000 Cc: Bitcoin Protocol Discussion 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: Fri, 18 Aug 2023 20:12:23 -0000 --0000000000005d67750603382589 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Symphonic, From a game-theory viewpoint where we define among other players utility functions, set of moves, rules of the games and pattern of information, I don't think oracles can be mathematically reduced to miners. Miners are competing to generate a proof-of-work on a set of transactions. This proof-of-work requires hashrate capabilities investment and censoring LN time-sensitive transactions impacting their marginal gains in the mining competitions to sustain the investment renewment in their mining chips. On the other hand, anyone can show as a proof-of-real-world-state oracle, without mining investment. They will take a while to build a reputation as a UTXO state oracle and even in case of wrongdoing, laziness is hard to prove [0]. To the best of my knowledge, there is no complete and practical security model for "DLC-like" oracles, as such it's hard to have the epistemological discussion on which assumptions should be regarded as valid or excluded from the formalization. As a note the CLTV-timelock matter for LN-like protocol, beyond CSV and here you start to have interactions with timewarp inflation attacks, which is still not fixed as a consensus-level vulnerability [1]. I think my previous statement that the addition of cross-UTXO covenant inspection raises risks in the lack of further R&D on the security model and the game-theory of Bitcoin is still correct. While a risk zero is not an intellectual mirage, at the very least when we're talking about the consensus rules of a $500 B ecosystem, we should bind to world-class standards of software engineering R&D. And as the ecosystem grows, I think we should aim to match best practices in aircraft software design or nuclear reactors. Best, Antoine [0] https://github.com/discreetlogcontracts/dlcspecs/pull/152 [1] https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawik= i Le lun. 14 ao=C3=BBt 2023 =C3=A0 15:07, symphonicbtc a =C3=A9crit : > > 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 t= o > censor the confirmation of time-sensitive lightning channel transactions, > where the bribes are paid on the hashrate distribution of miners during t= he > 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/021= 395.html > > Hi Antoine, > > These two papers make a lot of incorrect assumptions about bitcoins > security model. The assumption of the existence of constructs such as > oracles or altchains for =E2=80=9Ctrustless=E2=80=9D out-of-band payments= opens the door > for plenty of things that in reality are not possible without sacrificing > security. The assumption that these constructs =E2=80=9Cminimize=E2=80=9D= miner / attacker > trust is no better than assuming the existence of an oracle that can simp= ly > perform the entire attack. > > Moreover, even the limited examples of attacks that do not use these > constructs completely overlook the fact that bitcoins security model is > dependent on the preservation of the nash equilibrium between miners. Not > only is it disincentivized for miners to engage in any form of censorship= , > because they can all be fired by node-runners at any time, it is also not > in miners interests to reorg the chain if say an anonymous miner mines so= me > transactions that were being censored. Sustained, successful censorship i= n > any capacity assumes that bitcoin is compromised, a 51% attack has > occurred, and necessitates a change in PoW algorithm. A sufficient CSV in > LN-like protocols is always sufficient to avoid being attacked in this wa= y. > > The addition of most forms of covenant does not assist any of these > attacks afaict because they already make assumptions rendering them inval= id. > > > Symphonic > > ------- Original Message ------- > On Monday, August 14th, 2023 at 3:00 AM, Antoine Riard via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > 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 t= o > censor the confirmation of time-sensitive lightning channel transactions, > where the bribes are paid on the hashrate distribution of miners during t= he > 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/021= 395.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.= html > > > > > 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 adde= d > > > 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 committe= d > as part of the input scriptpubkey, and spend it on > blessed-with-one-participant-sig script. There is still a big open questi= on > 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 adde= d > > > 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 frau= d > > > 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 > --0000000000005d67750603382589 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Symphonic,

From a game-theory viewpo= int where we define among other players utility functions, set of moves, ru= les of the games and pattern of information, I don't think oracles can = be mathematically reduced to miners.

Miners are co= mpeting to generate a proof-of-work on a set of transactions. This proof-of= -work requires hashrate capabilities investment and censoring LN time-sensi= tive transactions impacting their marginal gains in the mining competitions= to sustain the investment renewment in their=C2=A0mining chips.
=
On the other hand, anyone can show as a proof-of-real-world-= state oracle, without mining investment. They will take a while to build a = reputation as a UTXO state oracle and even in case of wrongdoing, laziness= =C2=A0is hard to prove [0].

To the best of my know= ledge, there is no complete and practical security model for "DLC-like= " oracles, as such it's hard to have the epistemological discussio= n on which assumptions should be regarded as valid or excluded from the for= malization.

As a note the CLTV-timelock matter for= LN-like protocol, beyond CSV and here you start to have interactions with = timewarp inflation attacks, which is still not fixed as a consensus-level v= ulnerability [1].

I think my previous statement th= at the addition of cross-UTXO covenant inspection raises risks in the lack = of further R&D on the security model and the game-theory of Bitcoin is = still correct. While a risk zero is not an intellectual mirage, at the very= least when we're talking about the consensus rules of a $500 B ecosyst= em, we should bind to world-class standards of software engineering R&D= . And as the ecosystem grows, I think we should=C2=A0aim=C2=A0to match best= practices in aircraft software design or nuclear reactors.

Le=C2=A0lun. 14 ao=C3=BBt 2023 =C3=A0=C2=A015:07, sympho= nicbtc <symphonicbtc@proton.me= > a =C3=A9crit=C2=A0:
> I think cross-i= nput inspection (not cross-input signature aggregation which is different) = is opening a pandora box in terms of "malicious" off-chain contra= cts than one could design. E.g miners bribing contracts to censor the confi= rmation of time-sensitive lightning channel transactions, where the bribes = are paid on the hashrate distribution of miners during the previous difficu= lty period, thanks to the coinbase pubkey.
>
> See https://blog.bitmex.com/txwithhold-smart= -contracts/ and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/0213= 95.html

Hi Antoine,

These two papers make a lot of incorrect assumptions about bitcoins securit= y model. The assumption of the existence of constructs such as oracles or a= ltchains for =E2=80=9Ctrustless=E2=80=9D out-of-band payments opens the doo= r for plenty of things that in reality are not possible without sacrificing= security. The assumption that these constructs =E2=80=9Cminimize=E2=80=9D = miner / attacker trust is no better than assuming the existence of an oracl= e that can simply perform the entire attack.

Moreover, even the limited examples of attacks that do not use these constr= ucts completely overlook the fact that bitcoins security model is dependent= on the preservation of the nash equilibrium between miners. Not only is it= disincentivized for miners to engage in any form of censorship, because th= ey can all be fired by node-runners at any time, it is also not in miners i= nterests to reorg the chain if say an anonymous miner mines some transactio= ns that were being censored. Sustained, successful censorship in any capaci= ty assumes that bitcoin is compromised, a 51% attack has occurred, and nece= ssitates a change in PoW algorithm. A sufficient CSV in LN-like protocols i= s always sufficient to avoid being attacked in this way.

The addition of most forms of covenant does not assist any of these attacks= afaict because they already make assumptions rendering them invalid.


Symphonic

------- Original Message -------
On Monday, August 14th, 2023 at 3:00 AM, Antoine Riard via bitcoin-dev <= = bitcoin-dev@lists.linuxfoundation.org> wrote:


> Hi Salvatore,
> > This also allows inspection of other inputs, that was not possibl= e 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&qu= ot; off-chain contracts than one could design. E.g miners bribing contracts= to censor the confirmation of time-sensitive lightning channel transaction= s, 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/0213= 95.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 b= e 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 c= hannels and payment pools.
>
> > A flag can disable this behavior"
>
> More than a binary flag like a matrix could be introduced to encode su= bset of introspected inputs /outputs to enable sighash_group-like semantic:=
> https://lists.linu= xfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
>
> > 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_I= NPUT
> > 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 bitco= in transaction / script data types (e.g scriptpubkey, amount, nsequence, me= rkle branch) that could be fetched from the taproot annex.
>
> > After the evaluation of all inputs, it is verified that each outp= ut'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 fann= ing-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 t= ime.
>
> I think this generic framework is interesting for joinpool / coinpool = / payment pool, as you can check that any withdrawal output can be committe= d as part of the input scriptpubkey, and spend it on blessed-with-one-parti= cipant-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 m= alleability 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 inp= ut in the ranges of current transaction spend allowed to propagate on the n= etwork today.
>
> Thanks for the proposal,
>
> Best,
> Antoine
>
>
>
> Le dim. 30 juil. 2023 =C3=A0 22:52, Salvatore Ingala via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
> > Hi all,
> >
> > I have put together a first complete proposal for the core opcode= s 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 f= or
> > 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<= br> > > OP_CHECKCONTRACTVERIFY (CCV). An additional `flags` parameter all= ows
> > to specify if the opcode operates on an input or an output.
> > This also allows inspection of other inputs, that was not possibl= e
> > with the original opcodes.
> > - For outputs, the default behavior is to have the following defe= rred
> > checks mechanism for amounts: all the inputs that have a CCV towa= rds
> > 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 or= der
> > 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 Scrip= ts).
> >
> > ## Semantics
> >
> > The new OP_CHECKCONTRACTVERIFY takes 5 parameters from the stack:=
> >
> > <data>, <index>, <pk>, <taptree>, <fla= gs>
> >
> > The core logic of the opcode is as follows:
> >
> > "Check if the <index>-th input/output's scriptPubK= ey is a P2TR
> > whose public key is obtained from <pk>, (optionally) tweake= d 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&#= 39;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_I= NPUT
> > 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 outp= ut's bucket.
> >
> > After the evaluation of all inputs, it is verified that each outp= ut'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 t= ime.
> >
> > With this new opcode, the full generality of MATT (including the = fraud
> > proofs) can be obtained with just two opcodes: OP_CHECKCONTRACTVE= RIFY
> > and OP_CAT.
> > However, additional opcodes (and additional introspection) would<= br> > > surely benefit some applications.
> >
> > I look forward to your comments, and to start drafting a BIP prop= osal.
> >
> > Best,
> > Salvatore Ingala
> >
> >
> > [*] - Credits go to James O'Beirne for this approach, taken f= rom 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] - htt= ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.h= tml
> > [3] - https:= //lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html
> > [4] - https://github.com/bitcoin-inquisition/bitcoin/compare/24.0.= ..Merkleize:bitcoin:checkcontractverify
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundatio= n.org/mailman/listinfo/bitcoin-dev
--0000000000005d67750603382589--