MIME-Version: 1.0
References: <CAMhCMoFYF+9NL1sqKfn=ma3C_mfQv7mj2fqbqO5WXVwd6vyhLw@mail.gmail.com>
 <CALZpt+F251k7gSpogwFYHxFtGxc_tZjB4UU4SVEr=WvrsyMVMQ@mail.gmail.com>
 <CAMhCMoG+UWSWNbRMckgj1tUufofSLcs5DPM48f+X9o5y-=Y3QA@mail.gmail.com>
In-Reply-To: <CAMhCMoG+UWSWNbRMckgj1tUufofSLcs5DPM48f+X9o5y-=Y3QA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 15 Sep 2023 01:23:31 +0100
Message-ID: <CALZpt+G_tntsKxui9UOeF2SzEfYHL5avUe=WzhBt9C3ZnuCzpw@mail.gmail.com>
To: Salvatore Ingala <salvatore.ingala@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000165ff306055aceca"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concrete MATT opcodes
Precedence: list

--000000000000165ff306055aceca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Salvatore,

Thanks for the additional insights.

> 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.

Thinking more, I wonder if the following conjecture could be sketched out
e.g "any utxo-inspecting based miners bribing contracts know a
`counter-bribing` contract that can be offered by a honest Lightning
channel counterparty".

UTXO-inspection can be leveraged to offer "fee bounties" if a Lightning
funding UTXO is unspent after X and there is some ongoing anomaly suspected
(e.g miner-censorship)

> 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.

I looked at the gist and the sequence of transactions is still a bit
unclear to me. From my understanding:
- Alice and Bob both creates virtual UTXOs
- the asymmetric update transactions are valid at the condition of spending
a lower-state number virtual UTXO
- any new update transaction is committing to an on-chain virtual UTXO of a
higher state number

If I'm correct the construction sounds work to me, however I think it
sounds slightly less economically efficient than OG Eltoo (as presented in
2018 paper).

> 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 think this is still a good design question if we could prevent recursive
covenants that could be hijacked by censorship adversaries. Maybe
recursivity-enablement could be safeguarded on a timelock allowing escape
out of the recursivity after X blocks.

> 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?

Yes, the link about sighash_group-like talk about the use-case of
(non-interactive) aggregation of pre-signed LN commitment transactions with
a single pair of input / output iirc. Witness space efficiency benefit for
LSP and Lightning nodes with hundreds of channels to be closed.

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

https://github.com/bitcoin/bips/pull/1381 and let's say you have
`OP_PUSH_ANNEX_TAG(t)` where `t` is the type of tag queried. I wonder if
you could re-build a more powerful CHECKSIGFROMSTACK combined with
CHECKCONTRACTVERIFY.

> More generic introspection might not fit well within the semantics of
CCV, but it could (and probably should) be added with separate opcodes.

I think more witness space efficiency could be obtained by casting the CCV
hash as a merkle tree and traverse it a la g'root
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.ht=
ml

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

I agree it's more natural to leverage OP_CHECKSIGFROMSTACK to enable amount
transfer validation, however far less efficient in terms of witness space.

> 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 execute=
d
> OP_CHECKCONTRACTVERIFY opcodes (transaction-wide) that check the output
amount.

At first sight, n_outputs + n_ccv_out sounds indeed cheap. Though I think
this is yet to see how it interferes with spending script max opcode limits
and max transaction size.

Best,
Antoine

Le ven. 18 ao=C3=BBt 2023 =C3=A0 16:08, Salvatore Ingala <salvatore.ingala@=
gmail.com>
a =C3=A9crit :

> 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 bribin=
g
>> 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 pub=
key.
>>
>
> 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 i=
t
> 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 subse=
t
>> 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 committ=
ed
>> as part of the input scriptpubkey, and spend it on
>> blessed-with-one-participant-sig script. There is still a big open quest=
ion
>> 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-rela=
y,
>> 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
>
>

--000000000000165ff306055aceca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Salvatore,<div><br></div><div>Thanks for the additional=
 insights.</div><div><br></div><div>&gt; At this time, my=C2=A0goal is to f=
acilitate maximum experimentation; it&#39;s safe to open Pandora&#39;s box =
in a sandbox, as that&#39;s the only way to know if it&#39;s empty.<br>&gt;=
 Concerns will of course need to be answered when a soft-fork proposal is m=
ade, and restrictions can be added if necessary.<br></div><div><br></div><d=
iv>Thinking more, I wonder if the following conjecture could be sketched ou=
t e.g &quot;any utxo-inspecting based miners bribing contracts know a `coun=
ter-bribing` contract that can be offered by a honest Lightning channel cou=
nterparty&quot;.</div><div><br></div><div>UTXO-inspection can be leveraged =
to offer &quot;fee bounties&quot; if a Lightning funding UTXO is unspent af=
ter X and there is some ongoing anomaly suspected (e.g miner-censorship)=C2=
=A0</div><div><br></div><div>&gt; Cross-input introspection seems very like=
ly to have use cases; for example, I drafted some notes on how it could be =
used to implement eltoo-style replacement for lightning</div><div>&gt; (or =
arbitrary state channels) when combined with ANYONECANPAY:=C2=A0<a href=3D"=
https://gist.github.com/bigspider/041ebd0842c0dcc74d8af087c1783b63" target=
=3D"_blank">=C2=A0https://gist.github.com/bigspider/041ebd0842c0dcc74d8af08=
7c1783b63</a>. Although, it would be much ?</div><div>&gt; easier with CCV+=
CHECKSIGFROMSTACK, and in that case cross-input introspection=C2=A0is not n=
eeded.<br></div><div><br></div><div>I looked at the gist and the sequence o=
f transactions is still a bit unclear to me. From my understanding:</div><d=
iv>- Alice and Bob both creates virtual UTXOs</div><div>- the asymmetric up=
date transactions are valid at the condition of spending a lower-state numb=
er virtual UTXO</div><div>- any new update transaction is committing to an =
on-chain virtual UTXO of a higher state number</div><div><br></div><div>If =
I&#39;m correct the construction sounds work to me, however I think it soun=
ds slightly less economically efficient than OG Eltoo (as presented in 2018=
 paper).</div><div><br></div><div>&gt; Similarly, some people raised concer=
ns with recursivity of covenant opcodes; that also could be artificially li=
mited in CCV if desired, but it would prevent some use cases.<br></div><div=
><br></div><div>I think this is still a good design question if we could pr=
event recursive covenants that could be hijacked by censorship adversaries.=
 Maybe recursivity-enablement could be safeguarded on a timelock allowing e=
scape out of the recursivity after X blocks.</div><div><br></div><div>&gt; =
The flags alter the semantic behavior of the opcode; perhaps you rather ref=
er to generalizing the index parameter so that it can refer to a group of i=
nputs/outputs, instead?<br><br></div><div>Yes, the link about sighash_group=
-like talk about the use-case of (non-interactive) aggregation of pre-signe=
d LN commitment transactions with a single pair of input / output iirc. Wit=
ness space efficiency=C2=A0benefit for LSP and Lightning nodes with hundred=
s of channels to be closed.</div><div><br></div><div><div>&gt; How would th=
ese &quot;tags&quot; interact with CHECKCONTRACTVERIFY? I don&#39;t quite u=
nderstand the use case.</div><div><br></div><div><a href=3D"https://github.=
com/bitcoin/bips/pull/1381">https://github.com/bitcoin/bips/pull/1381</a> a=
nd let&#39;s say you have `OP_PUSH_ANNEX_TAG(t)` where `t` is the type of t=
ag queried. I wonder if you could re-build a more powerful CHECKSIGFROMSTAC=
K=C2=A0combined with CHECKCONTRACTVERIFY.<br></div><div><br></div><div>&gt;=
 More generic introspection might not fit well within the semantics of CCV,=
 but it could (and probably should) be added with separate opcodes.<br></di=
v><div><br></div><div>I think more witness space efficiency could be obtain=
ed by casting the CCV hash as a merkle tree and traverse it a la g&#39;root=
=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
18-July/016249.html">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2018-July/016249.html</a></div><div><br></div><div>&gt; I personally find=
 OP_CHECKSIGFROMSTACK more natural when thinking about constructions with C=
CV; but most likely either would work here.<br></div><div><br></div><div>I =
agree it&#39;s more natural to leverage OP_CHECKSIGFROMSTACK to enable amou=
nt transfer validation, however far less efficient in terms of witness spac=
e.</div><div><br></div><div>&gt; The DeferredChecks added specifically for =
CCV has negligible cost, as it&#39;s just O(n_outputs=C2=A0+ n_ccv_out) whe=
re n_ccv_out=C2=A0is the number of executed</div><div>&gt; OP_CHECKCONTRACT=
VERIFY opcodes (transaction-wide) that check the output amount.<br></div><d=
iv><br></div><div>At first sight, n_outputs=C2=A0+ n_ccv_out sounds indeed =
cheap. Though I think this is yet to see how it interferes with spending sc=
ript max opcode limits and max transaction size.</div><div><br></div><div>B=
est,</div><div>Antoine</div></div></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 18 ao=C3=BBt 2023 =C3=A0=C2=
=A016:08, Salvatore Ingala &lt;<a href=3D"mailto:salvatore.ingala@gmail.com=
">salvatore.ingala@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div>Hi Antoine,</div><div><br></div><div>Thanks f=
or 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 href=3D"mailto:antoine.riard@gmail.com" target=3D"_blank">antoine.ria=
rd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
>I think cross-input inspection (not cross-input signature aggregation=C2=
=A0which is different) is opening a pandora box in terms of &quot;malicious=
&quot; off-chain contracts than one could design. E.g miners bribing contra=
cts to censor the confirmation of time-sensitive lightning=C2=A0channel tra=
nsactions, where the bribes=C2=A0are paid on the hashrate=C2=A0distribution=
 of miners during the previous difficulty period, thanks to the coinbase pu=
bkey.</div></div></blockquote><div><br>At this time, my=C2=A0goal is to fac=
ilitate maximum experimentation; it&#39;s safe to open Pandora&#39;s box in=
 a sandbox, as that&#39;s the only way to know if it&#39;s empty.<br>Concer=
ns will of course need to be answered when a soft-fork proposal is made, an=
d restrictions can be added if necessary.</div><div><br>Cross-input introsp=
ection seems very likely to have use cases; for example, I drafted some not=
es on how it could be used to implement eltoo-style replacement for lightni=
ng (or arbitrary state channels) when combined with ANYONECANPAY:=C2=A0<a h=
ref=3D"https://gist.github.com/bigspider/041ebd0842c0dcc74d8af087c1783b63" =
target=3D"_blank">=C2=A0https://gist.github.com/bigspider/041ebd0842c0dcc74=
d8af087c1783b63</a>. Although, it would be much easier with CCV+CHECKSIGFRO=
MSTACK, and in that case cross-input introspection=C2=A0is not needed.<br><=
/div><div><br></div><div>Similarly, some people raised concerns with recurs=
ivity of covenant opcodes; that also could be artificially limited in CCV i=
f desired, but it would prevent some use cases.<br><br></div><div>I have so=
me thoughts on why the fear of covenants=C2=A0might generally be unjustifie=
d,=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;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div>More than a binary flag like a matr=
ix could be introduced to encode subset of introspected inputs /outputs to =
enable sighash_group-like semantic:<br></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/0=
19243.html</a></div></div></blockquote><div><br>The flags alter the semanti=
c behavior of the opcode; perhaps you rather refer to generalizing the inde=
x 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 furthe=
r.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left=
-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Or even bey=
ond a matrix, it could be a set of &quot;tags&quot;. There could be a gener=
alized tag for unstructured data, and another one for bitcoin transaction /=
 script data types (e.g scriptpubkey, amount, nsequence, merkle branch) tha=
t could be fetched from the taproot annex.</div></div></blockquote><div><br=
></div><div>How would these &quot;tags&quot; interact with CHECKCONTRACTVER=
IFY? I don&#39;t quite understand the use case.</div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex"><div dir=3D"ltr"><div>I think this generic framework is interesti=
ng for joinpool / coinpool / payment pool, as you can check that any withdr=
awal output can be committed as part of the input scriptpubkey, and spend i=
t on blessed-with-one-participant-sig script. There is still a big open que=
stion if it&#39;s efficient in terms of witness space consumed.</div></div>=
</blockquote><div><br>More generic introspection might not fit well within =
the semantics of CCV, but it could (and probably should) be added with sepa=
rate opcodes.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-le=
ft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>That said=
, I still think you would need at least ANYPREVOUT and more malleability fo=
r the amount transfer validation as laid out above.</div></div></blockquote=
><div><br>I personally find OP_CHECKSIGFROMSTACK more natural when thinking=
 about constructions with CCV; but most likely either would work here.<br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div>Looking on the `DeferredChe=
ck` framework commit, one obvious low-level concern is the DoS risk for ful=
l-nodes participating in transaction-relay, and that maybe policy rules sho=
uld be introduced to keep the worst-CPU input in the ranges of current tran=
saction spend allowed to propagate on the network today.</div></div></block=
quote><div><br>Of course, care needs to be taken in general when designing =
new deferred checks, to avoid any sort of quadratic validation cost.<br>The=
 DeferredChecks added specifically for CCV has negligible cost, as it&#39;s=
 just O(n_outputs=C2=A0+ n_ccv_out) where n_ccv_out=C2=A0is the number of e=
xecuted OP_CHECKCONTRACTVERIFY opcodes (transaction-wide) that check the ou=
tput amount.<br><br>Best,<br>Salvatore<br><br></div></div></div>
</blockquote></div>

--000000000000165ff306055aceca--