path: root/00/26ec831ba625c4eb4bed84d53df022f36224ef

Return-Path: <salvatore.ingala@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 99921C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAMhCMoFYF+9NL1sqKfn=ma3C_mfQv7mj2fqbqO5WXVwd6vyhLw@mail.gmail.com>
 <CALZpt+F251k7gSpogwFYHxFtGxc_tZjB4UU4SVEr=WvrsyMVMQ@mail.gmail.com>
In-Reply-To: <CALZpt+F251k7gSpogwFYHxFtGxc_tZjB4UU4SVEr=WvrsyMVMQ@mail.gmail.com>
From: Salvatore Ingala <salvatore.ingala@gmail.com>
Date: Fri, 18 Aug 2023 17:08:39 +0200
Message-ID: <CAMhCMoG+UWSWNbRMckgj1tUufofSLcs5DPM48f+X9o5y-=Y3QA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <antoine.riard@gmail.com> 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
<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

<div dir=3D"ltr"><div>Hi Antoine,</div><div><br></div><div>Thanks for your =
comments and insights.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Mon, 14 Aug 2023 at 05:01, Antoine Riard &lt;<a hr=
ef=3D"mailto:antoine.riard@gmail.com" target=3D"_blank">antoine.riard@gmail=
.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div>I think cross-input inspection (not cross-input s=
ignature aggregation=C2=A0which is different) is opening a pandora box in t=
erms of &quot;malicious&quot; 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.</div></div></blockquote><div><br>At this time,=
 my=C2=A0goal is to facilitate maximum experimentation; it&#39;s safe to op=
en Pandora&#39;s box in a sandbox, as that&#39;s the only way to know if it=
&#39;s empty.<br>Concerns will of course need to be answered when a soft-fo=
rk proposal is made, and restrictions can be added if necessary.</div><div>=
<br>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<a href=3D"https://gist.github.com/bigspider/041ebd0842c=
0dcc74d8af087c1783b63">=C2=A0https://gist.github.com/bigspider/041ebd0842c0=
dcc74d8af087c1783b63</a>. Although, it would be much easier with CCV+CHECKS=
IGFROMSTACK, and in that case cross-input introspection=C2=A0is not needed.=
<br></div><div><br></div><div>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.<br><br></div><div>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.<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv>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:<b=
r></div><div><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2021-July/019243.html" target=3D"_blank">https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2021-July/019243.html</a></div></div></blockquot=
e><div><br>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?<br>I&#39;m not aware of the use cases at=
 this time, feel free to expand further.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><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></blockquote><div><br></d=
iv><div>How would these &quot;tags&quot; interact with CHECKCONTRACTVERIFY?=
 I don&#39;t quite understand the use case.</div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>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&#39;s efficient in terms of witnes=
s space consumed.</div></div></blockquote><div><br>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.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>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.</div></div></blockquote><div><br>I=
 personally find OP_CHECKSIGFROMSTACK more natural when thinking about cons=
tructions with CCV; but most likely either would work here.<br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>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.</div></div></blockquote><div><br>Of course, care needs to be taken in g=
eneral when designing new deferred checks, to avoid any sort of quadratic v=
alidation cost.<br>The DeferredChecks added specifically for CCV has neglig=
ible cost, as it&#39;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.<br><br>Best,<br>Salvatore<br><br></div=
></div></div>

--000000000000fff40b060333e750--