Salvatore Ingala [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-18 🗒️ Summary of this message: Antoine ...
📅 Original date posted:2023-08-18
🗒️ Summary of this message: Antoine expressed concerns about the potential risks of cross-input inspection, but the response emphasized the importance of experimentation. Cross-input introspection has potential use cases, such as implementing eltoo-style replacement for lightning. The idea of using flags or tags to encode subset of introspected inputs/outputs was discussed, but further clarification is needed. The potential efficiency of this framework in terms of witness space consumed is still an open question.
📝 Original message:
Hi Antoine,
Thanks for your comments and insights.
On Mon, 14 Aug 2023 at 05:01, Antoine Riard <antoine.riard at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230818/e7955d4b/attachment.html>;
🗒️ Summary of this message: Antoine expressed concerns about the potential risks of cross-input inspection, but the response emphasized the importance of experimentation. Cross-input introspection has potential use cases, such as implementing eltoo-style replacement for lightning. The idea of using flags or tags to encode subset of introspected inputs/outputs was discussed, but further clarification is needed. The potential efficiency of this framework in terms of witness space consumed is still an open question.
📝 Original message:
Hi Antoine,
Thanks for your comments and insights.
On Mon, 14 Aug 2023 at 05:01, Antoine Riard <antoine.riard at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230818/e7955d4b/attachment.html>;