Re: [bitcoin-dev] Concrete MATT opcodes

[Antoine Riard <antoine.riard@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8418 bytes --]

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

> 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 executed
> 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ût 2023 à 16:08, Salvatore Ingala <salvatore.ingala@gmail.com>
a écrit :

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

[-- Attachment #2: Type: text/html, Size: 11131 bytes --]