Okay so yes to be precise, it was more on the theoretical / primitive design space technical options, in the sense that I don’t think we have seen primitives breakthrough since OP_TLUV, OP_EVICT, MATT or PT2R merkle tree editors since few years ago. The only recent breakthrough have been constructions like BitVM or ColliderScript, to attempt to achieve the same for some use-cases, without consensus changes.
Though yes, getting industry’s opinions on how they would see vaults in practice, and not only on whiteboard is a notable move forward, I do not disagree. IMHO, the more interesting question, I was laying is if HW / secure enclave vendors would be ready to have CTV-like support on the enclave-side, otherwise it’s “blind signing” for the key ceremonies (cf. “Blind Signing Considered Harmful”).
In my perspective, the only security property improvement, that one can argue on is immutability, that once the coins are deposited on-chain beyond reorgs, there is no more reliance on correct and secure key-deletion for the intermediary unvaulting transactions.
From browsing the Nunchuk, McElrath and Wizardsardine viewpoints, if I’m understanding correctly they’re saying either (a) vault it’s hard because reactive model (so chain monitoring or watchtower) or (b) vault it’s hard because duplicate set of keys. To have researched in the past extensively second-layers threats models (cf. L2 Transaction-Relay Workshops), vault security model is not more complex than Lightning, and while LN is plagued by security vulnerabilities and limitations, courageous wallet vendors have succeeded to integrate it on mobile and desktop wallets. Of course, key ceremonies is a hard thing for vaults, i.e dealing well the transition from cold storage, though it’s that harder than managing seeds transfers on multiple platforms for LN, and inadvertently broadcasting an already revoked state ? I don’t think so…
Contrary to LN, vaults are not stateful, in the sense of off-chain update with a counterparty. This is already far less complexity, imo.
Fwiw, if we wish to have LN-Symmetry / Eltoo, we should just do ANYPREVOUT. I think OP_CSFS enhances the range of TxWithhold contract, as you can pass now a signature for a tx, you’re not a counterparty to (i.e not a pubkey in a 2-of-2 P2WSH), which can be concerned for already deployed L2s like Lightning.
I do not disagree that we should avoid to go for legacy script, avoids making the DoS surface worst (e.g worst-block case). I’m re-reading BIP119 though there is no footnote to explain why OP_NOP4
vs another upgrade path (e.g tapleaf version or OP_SUCCESS
).
Doing an OP_PUSH <template>
instead of a OP_CHECK <template>
, that means now you have a comparison on the Script stack to be done between <pushed_template>
and <reference_template>
. I do no think something in terms of <template>
bad malleability it’s an issue (hmm…), however it’s more memory allocated among the different script ops on the stack by each full-nodes. Not sure it’s a concern.