From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 33E17C0032 for ; Wed, 13 Sep 2023 20:25:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 19B8481F4C for ; Wed, 13 Sep 2023 20:25:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 19B8481F4C Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=cXnOtcTN 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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vunX6xVIHt3y for ; Wed, 13 Sep 2023 20:25:20 +0000 (UTC) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) by smtp1.osuosl.org (Postfix) with ESMTPS id 0FF02813E8 for ; Wed, 13 Sep 2023 20:25:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0FF02813E8 Received: by mail-il1-x12d.google.com with SMTP id e9e14a558f8ab-34ccedcc584so871845ab.0 for ; Wed, 13 Sep 2023 13:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694636719; x=1695241519; darn=lists.linuxfoundation.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nA3o72Jlatg4dOZ2bT5JMSkAG1feQv1H6jJtBXWuhSc=; b=cXnOtcTNCq1splhKNL9AjDmh3rsbSmf1Zp/JrHHUjCwBco5KBdUD7z5eYFyL+L/0Kt 0DEHFaNWSfM/upQUUh8qsLjm+ehi4ovVJeeADqEyV2bBvx5onuI6apCwga4HNpy4Og4k d5OlXc73jePDQe2OqWVctnX+PkABwuq5UfO6hYWdkJuP3ZBFnbfXEzPyEz1P5NY/X3Ct mzMXoWJi5Ol58h0LMJeweamS3ejw/zjBWka8hovLRu450Xd3JAVhsGAJboZlo4oKdtqJ vBK0e/lNAFUCLY3vwB4xqHpDyDsSbodNrD705wU+uyacJQY2v0UNGs+qp4whsJJd3Qj9 /l0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694636719; x=1695241519; 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=nA3o72Jlatg4dOZ2bT5JMSkAG1feQv1H6jJtBXWuhSc=; b=EJVmdaUjEWw1fXxYN1PpHXktS70YALUWLpLb2J6pEHEpPb60PwXl8l0NaKN2osBSaM zs2bY6RyF9Ty1IiX8+XHJIi0OmPNRxZLxB93M/toCCuSz9k+hwcovEBV/Mt9Vfj78yex 90aIPBE1bEy7wZQyG0h5qS6WBUlAUD7Jk7CXm21Meb9bPTWYSyg6vduXg9Ut/GcXwBKO 0W4Eow+ghpFd695XuhHAiF1W8kwHrNXxjHBPgECm+YwqdZzoQx5g1Pc7+i6yw9tJCcvL 1DcYnLKTKLwbxUig7JYbcSLFG4xnSvk35x1qLNuQU/TcAAFVwDt9g/jA25/C+rmAOxbk 352A== X-Gm-Message-State: AOJu0Yzq3cX/iyzu8p68Y8mDypAP1rmtVqEVmJN+YNJyrey3/kMaf1Hj 80gEsExMOSz+d4fzTzGmmWjyqyUBZSDynizS02l/Ibz/3zWU+Q== X-Google-Smtp-Source: AGHT+IF2GSyDSv8p1iwALi5aMjLth376ObpM6bZ1GqFFTX4hBeXUpu/wl1eVCm3C+9dCetdOI/KwIpNsel+Y0a8hqnc= X-Received: by 2002:a05:6e02:1c28:b0:34f:7b1e:c568 with SMTP id m8-20020a056e021c2800b0034f7b1ec568mr4335331ilh.3.1694636718958; Wed, 13 Sep 2023 13:25:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Wed, 13 Sep 2023 21:25:07 +0100 Message-ID: To: symphonicbtc Content-Type: multipart/alternative; boundary="000000000000a82c2f0605435b06" X-Mailman-Approved-At: Fri, 15 Sep 2023 13:48:53 +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: Wed, 13 Sep 2023 20:25:22 -0000 --000000000000a82c2f0605435b06 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Symphonic, I'm not aware of any theory of the "mining firm" (in the coasian sense) that would give the lineaments of the cost / income structure of a lambda mining operation, and from which to predict how a change in the withhold mined coins impact the long-term sustainability of their business, especially incorporating relationships with electricity providers and mining chips makers. On the impact of disregarding OFAC sanctioned txs, this sounds correct that as long as this is a minority of economic transactions that a mining operation can censor, they can afford to stay in business and not lose long-term blockspace issuance. If the regulation enforcement cost starts to be too high, they can move to a jurisdiction where regulation costs are lower [0]. This is indeed a good remark that is unclear if additional constructs and smart contracts would incentive block-reorgs or transactions censoring attitudes, or even if we would see "lightning-bounty" transactions constructs happening generating an economic equilibrium between censorship and confirmation. I think this is an area deserving more research for sure. This is unclear if reduction of the timewarp attack too could modify the miners incentives equilibrium [1]. In the end I can only agree that miners and full-nodes operators incentives should be a built-in protection in case of consensus upgrades substantially altering the Bitcoin deep security model. The thing is this model is very unclear to the best of my knowledge and I don't think anyone has taken time to formalize it from the years of blocksize wars from then to analyze carefully proposed covenant upgrades. Best, Antoine [0] Side-note and IANA disclaimer. On the application to US OFAC by Bitcoin economic entities operators, there is a huge uncertainty if naive application of OFAC is respecting the EU GDPR, the article 8 of the CEDH and what is left of Roe vs Wade in the US in terms of constitutional protections. If you're a human right activist, you have time to dedicate yourself on years-long issues and you have the dual-level of legal and technical expertise, I would invite you to open litigations against mining pools and chainanalysis companies in this space. While European and US jurisdictions have clear traditional constitutional protections and legal remedies to protect the end-users zone of data autonomy, I'm incredibly worried w.r.t to non-Western based jurisdictions less concerned with human rights, where chainanalysis companies might do ethically concerning things. [1] Putting back https://bitcoinops.org/en/topics/consensus-cleanup-soft-fork/ on the consensus upgrade table I think it would be great to address Bitcoin consensus "technical debt" and simplify the design and analysis of covenants and second-layers protocols. 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 > --000000000000a82c2f0605435b06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Symphonic,

I'm not aware of any = theory of the "mining firm" (in the coasian sense) that would giv= e the lineaments of the cost / income structure of a lambda mining operatio= n, and from which to predict how a change in the withhold mined coins impac= t the long-term sustainability of their business, especially incorporating = relationships with electricity providers and mining chips makers.

On the impact of disregarding OFAC sanctioned txs, this sou= nds correct that as long as this is a minority of economic transactions tha= t a mining operation can censor, they can afford to stay in business and no= t lose long-term blockspace issuance. If the regulation enforcement cost st= arts to be too high, they can move to a jurisdiction where regulation costs= are lower [0].

This is indeed a good remark that = is unclear if additional constructs and smart contracts would incentive blo= ck-reorgs or transactions censoring attitudes, or even if we would see &quo= t;lightning-bounty" transactions constructs happening generating an ec= onomic equilibrium between censorship and confirmation. I think this is an = area deserving more research for sure.

This is unc= lear if reduction of the timewarp attack too could modify the miners incent= ives equilibrium [1].

In the end I can only agree = that miners and full-nodes operators incentives should be a built-in protec= tion in case of consensus upgrades substantially altering the Bitcoin deep = security model. The thing is this model is very unclear to the best of my k= nowledge and I don't think anyone has taken time to formalize it from t= he years of blocksize wars from then to analyze carefully proposed covenant= upgrades.

Best,
Antoine
<= br>
[0] Side-note and IANA disclaimer. On the application to US O= FAC by Bitcoin economic entities operators, there is a huge uncertainty if = naive application of OFAC is respecting the EU GDPR, the article 8 of the C= EDH and what is left of Roe vs Wade in the US in terms of constitutional pr= otections. If you're a human right activist, you have time to dedicate = yourself on years-long issues and you have the dual-level of legal and tech= nical expertise, I would invite you to open litigations against mining pool= s and chainanalysis companies in this space. While European and US jurisdic= tions have clear traditional constitutional protections and legal remedies = to protect the end-users zone of data autonomy, I'm incredibly worried = w.r.t to non-Western based jurisdictions less concerned with human rights, = where chainanalysis companies might do ethically concerning things.

[1] Putting back https://bitcoinops.org/en/topics/consensu= s-cleanup-soft-fork/ on the consensus upgrade table I think it would be= great to address Bitcoin consensus "technical debt" and simplify= the design and analysis of covenants and second-layers protocols.


Le=C2=A0lun. 14 ao=C3=BBt 2023 =C3=A0=C2=A015:07, symphonicbtc = <symphonicbtc@proton.me>= ; a =C3=A9crit=C2=A0:
> I think cross-input in= spection (not cross-input signature aggregation which is different) is open= ing a pandora box in terms of "malicious" off-chain contracts tha= n one could design. E.g miners bribing contracts to censor the confirmation= of time-sensitive lightning channel transactions, where the bribes are pai= d on the hashrate distribution of miners during the previous difficulty per= iod, 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
--000000000000a82c2f0605435b06--