From: Salvatore Ingala <salvatore.ingala@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concrete MATT opcodes
Date: Fri, 18 Aug 2023 17:08:39 +0200 [thread overview]
Message-ID: <CAMhCMoG+UWSWNbRMckgj1tUufofSLcs5DPM48f+X9o5y-=Y3QA@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+F251k7gSpogwFYHxFtGxc_tZjB4UU4SVEr=WvrsyMVMQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3964 bytes --]
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: 5526 bytes --]
next prev parent reply other threads:[~2023-08-18 15:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-30 21:37 Salvatore Ingala
2023-08-06 20:13 ` David A. Harding
2023-08-07 8:31 ` Salvatore Ingala
2023-08-07 11:37 ` Johan Torås Halseth
2023-08-09 8:38 ` Salvatore Ingala
2023-08-14 3:00 ` Antoine Riard
2023-08-14 14:07 ` symphonicbtc
2023-08-18 20:12 ` Antoine Riard
2023-08-19 23:11 ` symphonicbtc
2023-09-13 20:25 ` Antoine Riard
2023-08-18 15:08 ` Salvatore Ingala [this message]
2023-09-15 0:23 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMhCMoG+UWSWNbRMckgj1tUufofSLcs5DPM48f+X9o5y-=Y3QA@mail.gmail.com' \
--to=salvatore.ingala@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox