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.ing...@gmail.com> a écrit : > Hi Antoine, > > Thanks for your comments and insights. > > On Mon, 14 Aug 2023 at 05:01, Antoine Riard <antoine.ri...@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 > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
