Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6AFADC0032 for ; Mon, 14 Aug 2023 14:07:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 4479940B4F for ; Mon, 14 Aug 2023 14:07:49 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4479940B4F Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=proton.me header.i=@proton.me header.a=rsa-sha256 header.s=qpgfc4yj7zbxxo7ly4hq3olk5y.protonmail header.b=HX0dvlr7 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 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, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_PASS=-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 VgFPHpIWveYf for ; Mon, 14 Aug 2023 14:07:47 +0000 (UTC) Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch [185.70.41.103]) by smtp2.osuosl.org (Postfix) with ESMTPS id E213F4062A for ; Mon, 14 Aug 2023 14:07:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E213F4062A Date: Mon, 14 Aug 2023 14:07:19 +0000 Authentication-Results: mail-41103.protonmail.ch; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="HX0dvlr7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=qpgfc4yj7zbxxo7ly4hq3olk5y.protonmail; t=1692022050; x=1692281250; bh=Wl+06Lu7Btur2ChsKz0O2rIs4SEeRCnN01y95beJ9VQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=HX0dvlr7hBBsUYUAnjO+gvfo2fof7k5Yw8uynDbDzQGR9ZlspnrmHtrxII65Kn4XB umnzBe5gn8XFMx+xCG3tgt9ci48jF9CMuckuOJ2BaulFReoKLChmaBrOfPNutczFhC m7yyy+abk8hGwmirUL5FAObA6Gq5ZYDwVfvmBZ8aLEoHcBCjwbXxVQolhcabC+noCS L9fzFo70fbzdId7WJvI4qyhJU6hnyA02kxuNyVZVZAT1VBI5GuQ5Q9NDGPF9Y0J4vI HMJ1k5ucuk/j5+I3Tenvw9LGCRMOTweEY+FeBsuVu+SnLr6mtV0iiEiokZDTBHX5Z9 60QGzSMASlRJQ== To: Antoine Riard From: symphonicbtc Message-ID: In-Reply-To: References: Feedback-ID: 77757318:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 14 Aug 2023 14:09:35 +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: Mon, 14 Aug 2023 14:07:49 -0000 > I think cross-input inspection (not cross-input signature aggregation whi= ch 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 th= e 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. >=20 > See https://blog.bitmex.com/txwithhold-smart-contracts/ and https://lists= .linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021395.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 o= racle 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 wrote: > Hi Salvatore, > > This also allows inspection of other inputs, that was not possible with= the original opcodes. >=20 > I think cross-input inspection (not cross-input signature aggregation whi= ch 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 th= e 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. >=20 > See https://blog.bitmex.com/txwithhold-smart-contracts/ and https://lists= .linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021395.html >=20 > 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 s= afe design practice to rule out those types of concerns thanks to smart bit= coin contracting primitives. >=20 > I think this is a common risk to all second-layers vaults, lightning chan= nels and payment pools. >=20 > > A flag can disable this behavior" >=20 > More than a binary flag like a matrix could be introduced to encode subse= t of introspected inputs /outputs to enable sighash_group-like semantic: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.= html >=20 > > 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. >=20 > Or even beyond a matrix, it could be a set of "tags". There could be a ge= neralized tag for unstructured data, and another one for bitcoin transactio= n / script data types (e.g scriptpubkey, amount, nsequence, merkle branch) = that could be fetched from the taproot annex. >=20 > > 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). >=20 > 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 thi= nk you would need more malleability here. >=20 > > 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. >=20 > I think this generic framework is interesting for joinpool / coinpool / p= ayment pool, as you can check that any withdrawal output can be committed a= s part of the input scriptpubkey, and spend it on blessed-with-one-particip= ant-sig script. There is still a big open question if it's efficient in ter= ms of witness space consumed. >=20 > That said, I still think you would need at least ANYPREVOUT and more mall= eability for the amount transfer validation as laid out above. >=20 > Looking on the `DeferredCheck` framework commit, one obvious low-level co= ncern is the DoS risk for full-nodes participating in transaction-relay, an= d 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 netw= ork today. >=20 > Thanks for the proposal, >=20 > Best, > Antoine >=20 >=20 >=20 > Le dim. 30 juil. 2023 =C3=A0 22:52, Salvatore Ingala via bitcoin-dev a =C3=A9crit : >=20 > > Hi all, > >=20 > > 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. > >=20 > > The code is implemented in the following fork of the > > bitcoin-inquisition repo: > >=20 > > https://github.com/Merkleize/bitcoin/tree/checkcontractverify > >=20 > > Therefore, it also includes OP_CHECKTEMPLATEVERIFY, as in a > > previous early demo for vaults [3]. > >=20 > > 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. > >=20 > > ## Changes vs the previous draft > >=20 > > 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). > >=20 > > ## Semantics > >=20 > > The new OP_CHECKCONTRACTVERIFY takes 5 parameters from the stack: > >=20 > > , , , , > >=20 > > The core logic of the opcode is as follows: > >=20 > > "Check if the -th input/output's scriptPubKey is a P2TR > > whose public key is obtained from , (optionally) tweaked with > > , (optionally) tap-tweaked with ". > >=20 > > The following are special values of the parameters: > >=20 > > - 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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). > >=20 > > ## Comment > >=20 > > 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. > >=20 > > 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. > >=20 > > I look forward to your comments, and to start drafting a BIP proposal. > >=20 > > Best, > > Salvatore Ingala > >=20 > >=20 > > [*] - 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. > >=20 > >=20 > > References: > >=20 > > [1] - https://merkle.fun/ > > [2] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Nove= mber/021182.html > > [3] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-Apri= l/021588.html > > [4] - https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Mer= kleize:bitcoin:checkcontractverify > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev