From: Antoine Riard <antoine.riard@gmail•com>
To: Salvatore Ingala <salvatore.ingala@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concrete MATT opcodes
Date: Fri, 15 Sep 2023 01:23:31 +0100 [thread overview]
Message-ID: <CALZpt+G_tntsKxui9UOeF2SzEfYHL5avUe=WzhBt9C3ZnuCzpw@mail.gmail.com> (raw)
In-Reply-To: <CAMhCMoG+UWSWNbRMckgj1tUufofSLcs5DPM48f+X9o5y-=Y3QA@mail.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 --]
prev parent reply other threads:[~2023-09-15 0:23 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
2023-09-15 0:23 ` Antoine Riard [this message]
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='CALZpt+G_tntsKxui9UOeF2SzEfYHL5avUe=WzhBt9C3ZnuCzpw@mail.gmail.com' \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=salvatore.ingala@gmail$(echo .)com \
/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