Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 99921C0032 for ; Fri, 18 Aug 2023 15:08:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 6E58960BF9 for ; Fri, 18 Aug 2023 15:08:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6E58960BF9 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=nEwAy8Gi X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 s3mkCTj3XMGU for ; Fri, 18 Aug 2023 15:08:52 +0000 (UTC) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) by smtp3.osuosl.org (Postfix) with ESMTPS id 2A62160BCE for ; Fri, 18 Aug 2023 15:08:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2A62160BCE Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-34bae4fa2a8so3503665ab.0 for ; Fri, 18 Aug 2023 08:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692371331; x=1692976131; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iS1TMoTxsG4Ed6S7KVARMQexZ8/+8dT7loU4TxBKAso=; b=nEwAy8Gi4sQGJooHkg6PpPzzqiaLBUW0Ad1hnCr0bB9msQqeMwtS2OzIcY687CxMNE 2M3rmVVUOfPa5MdFbFLcg1ix/7mfEDJeq9LCGFApaB9iA81aAlIjaVJKf4tf1NFZUe92 mWJjQ7AdbOu59eo1h8fiG69f4aA6G3je9WbkrkGP7LMZl1yq0hE8VncbhKEmV5o4EC6l N0jmS2s1B1Np4hp6bY30Esg9sikm0diAplU2xccNy8xmUo16Lk+e5KinSzRFrozuUl4u a2mCHsCIrrUs8C0zrcURilB+8FUHSUkP02M0+ULta+jOL4ljFQQBJ2FRCxiPWimWjNnQ aOfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692371331; x=1692976131; 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=iS1TMoTxsG4Ed6S7KVARMQexZ8/+8dT7loU4TxBKAso=; b=jEZtp5jwARdn/E1qp345tG6yXFKtBEwKPix+OHSIdazbhxnWJ6LrWyPftANTIenly4 oWKyBpHxNsy4IXG2SKx8nfgnyBEFhqjc40hrlcpcnClYEsHgOnT9sArmJSHGSRYmW/Pf ksqGFV4j96OEEdJtJ4rst4qibwGN1sR0vw3l5LKt92IyVrZ9/m5Y1knDyE2d4J478fH3 1L7FeSxaIZociTeARkHuRF+lgKB3tejHOpEzpvYBMJgScPkReztVLROXWv8i9RyslcX2 5NtTySOGM0ptbqpTidSFkS/tgwQLTB3WPSPqSV8GnQP6TVq8tFljpa/ncXsuAIxVjkEE 26yw== X-Gm-Message-State: AOJu0YxG/9zPgU/qlZYQkIwO46xLWbyadxnuvO/94tbZIK247zAi14kj pUwtuhWji10IDdfSyhYyE5Ks/emxO2gcYmiHiuOCs/ZN9rqjxg== X-Google-Smtp-Source: AGHT+IEZV17dHn2A+EWzQKiX39XMMNwYAZmPSbdOfBgkFV1qP9M0+4YcyQScufrg5eiRbTRAJ72EK8JDW4ev0i7HH78= X-Received: by 2002:a05:6e02:f4e:b0:348:fe78:e9d6 with SMTP id y14-20020a056e020f4e00b00348fe78e9d6mr3067001ilj.0.1692371330788; Fri, 18 Aug 2023 08:08:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Salvatore Ingala Date: Fri, 18 Aug 2023 17:08:39 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000fff40b060333e750" X-Mailman-Approved-At: Fri, 18 Aug 2023 15:20:23 +0000 Subject: Re: [bitcoin-dev] Concrete MATT opcodes X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2023 15:08:54 -0000 --000000000000fff40b060333e750 Content-Type: text/plain; charset="UTF-8" Hi Antoine, Thanks for your comments and insights. On Mon, 14 Aug 2023 at 05:01, Antoine Riard wrote: > 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. > At this time, my goal is to facilitate maximum experimentation; it's safe to open Pandora's box in a sandbox, as that's the only way to know if it's empty. Concerns will of course need to be answered when a soft-fork proposal is made, and restrictions can be added if necessary. Cross-input introspection seems very likely to have use cases; for example, I drafted some notes on how it could be used to implement eltoo-style replacement for lightning (or arbitrary state channels) when combined with ANYONECANPAY: https://gist.github.com/bigspider/041ebd0842c0dcc74d8af087c1783b63 . Although, it would be much easier with CCV+CHECKSIGFROMSTACK, and in that case cross-input introspection is not needed. Similarly, some people raised concerns with recursivity of covenant opcodes; that also could be artificially limited in CCV if desired, but it would prevent some use cases. I have some thoughts on why the fear of covenants might generally be unjustified, which I hope to write in long form at some point. 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 > The flags alter the semantic behavior of the opcode; perhaps you rather refer to generalizing the index parameter so that it can refer to a group of inputs/outputs, instead? I'm not aware of the use cases at this time, feel free to expand further. > 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. > How would these "tags" interact with CHECKCONTRACTVERIFY? I don't quite understand the use case. 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. > More generic introspection might not fit well within the semantics of CCV, but it could (and probably should) be added with separate opcodes. That said, I still think you would need at least ANYPREVOUT and more > malleability for the amount transfer validation as laid out above. > I personally find OP_CHECKSIGFROMSTACK more natural when thinking about constructions with CCV; but most likely either would work here. 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. > Of course, care needs to be taken in general when designing new deferred checks, to avoid any sort of quadratic validation cost. The DeferredChecks added specifically for CCV has negligible cost, as it's just O(n_outputs + n_ccv_out) where n_ccv_out is the number of executed OP_CHECKCONTRACTVERIFY opcodes (transaction-wide) that check the output amount. Best, Salvatore --000000000000fff40b060333e750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,

Thanks for your = comments and insights.

On Mon, 14 Aug 2023 at 05:01, Antoine Riard <antoine.riard@gmail= .com> wrote:
I think cross-input inspection (not cross-input s= ignature aggregation=C2=A0which is different) is opening a pandora box in t= erms of "malicious" off-chain contracts than one could design. E.= g miners bribing contracts to censor the confirmation of time-sensitive lig= htning=C2=A0channel transactions, where the bribes=C2=A0are paid on the has= hrate=C2=A0distribution of miners during the previous difficulty period, th= anks to the coinbase pubkey.

At this time,= my=C2=A0goal is to facilitate maximum experimentation; it's safe to op= en Pandora's box in a sandbox, as that's the only way to know if it= 's empty.
Concerns will of course need to be answered when a soft-fo= rk proposal is made, and restrictions can be added if necessary.
=
Cross-input introspection seems very likely to have use cases; for exam= ple, I drafted some notes on how it could be used to implement eltoo-style = replacement for lightning (or arbitrary state channels) when combined with = ANYONECANPAY:=C2=A0=C2=A0https://gist.github.com/bigspider/041ebd0842c0= dcc74d8af087c1783b63. Although, it would be much easier with CCV+CHECKS= IGFROMSTACK, and in that case cross-input introspection=C2=A0is not needed.=

Similarly, some people raised concerns with r= ecursivity of covenant opcodes; that also could be artificially limited in = CCV if desired, but it would prevent some use cases.

I ha= ve some thoughts on why the fear of covenants=C2=A0might generally be unjus= tified,=C2=A0which I hope to write in=C2=A0long form at some point.

=
More than a binary flag like a matrix could be introduced to encode subs= et of introspected inputs /outputs to enable sighash_group-like semantic:

The flags alter the semantic behavior of the opcode; perhaps you= rather refer to generalizing the index parameter so that it can refer to a= group of inputs/outputs, instead?
I'm not aware of the use cases at= this time, feel free to expand further.
=C2=A0
Or even beyond = a matrix, it could be a set of "tags". There could be a generaliz= ed tag for unstructured data, and another one for bitcoin transaction / scr= ipt data types (e.g scriptpubkey, amount, nsequence, merkle branch) that co= uld be fetched from the taproot annex.

How would these "tags" interact with CHECKCONTRACTVERIFY?= I don't quite understand the use case.

I think this g= eneric framework is interesting for joinpool / coinpool / payment pool, as = you can check that any withdrawal output can be committed as part of the in= put 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 witnes= s space consumed.

More generic introspecti= on might not fit well within the semantics of CCV, but it could (and probab= ly should) be added with separate opcodes.

That said, I still t= hink you would need at least ANYPREVOUT and more malleability for the amoun= t transfer validation as laid out above.

I= personally find OP_CHECKSIGFROMSTACK more natural when thinking about cons= tructions with CCV; but most likely either would work here.

Looki= ng on the `DeferredCheck` framework commit, one obvious low-level concern i= s 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 tod= ay.

Of course, care needs to be taken in g= eneral when designing new deferred checks, to avoid any sort of quadratic v= alidation cost.
The DeferredChecks added specifically for CCV has neglig= ible cost, as it's just O(n_outputs=C2=A0+ n_ccv_out) where n_ccv_out= =C2=A0is the number of executed OP_CHECKCONTRACTVERIFY opcodes (transaction= -wide) that check the output amount.

Best,
Salvatore

--000000000000fff40b060333e750--