Forwarding in some conceptual feedback from the pull request.
From ariard:
> I've few open questions, like if the recovery path should be committed with a signature rather than protected by a simple scriptpubkey preimage.
That's something I've wondered about too. I have to ruminate on AJ's good post about this, but a pretty straightforward way of enabling this (at the expense of some complexity) is to do something like "if <recovery-path-hash> is 32 bytes, treat it as it's currently used. If it's 33 bytes, use the first byte as a parameter for how to interpret it." To start with, an extra prefix byte of 0x00 could mean "require a witness satisfying the scriptPubKey that hashes to the remaining 32 bytes" in the same way we do the unvault signing. This would enable a "sign-to-recover" flow at the option of the user, specified during vault creation.
> The current OP_VAULT implementation is using OP_NOP repurposing but this doesn't seem compatible with Taproot-only extensions (e.g ANYPREVOUT) and maybe a OP_SUCCESS could be used.
Yes, with Greg's suggestion of putting <target-hash> on the witness stack during OP_VAULT (-> OP_UNVAULT) spend, we could conceivably move OP_VAULT/OP_UNVAULT into Taproot-only OP_SUCCESSx opcodes. I haven't thought hard about how worthwhile it is to preserve the ability to use OP_VAULT in pre-Taproot contexts.
> There is a conceptual wonder, if a CTV and template malleability approach wouldn't better suit the vault use-case and allow other ones, as such better re-usability of primitives.
I dedicated a whole section of the paper ("Precomputed vaults with covenants") to explaining why precomputed covenant mechanisms have big shortcomings for vaults.
That said, a number of people have commented about OP_VAULT's ability to (inefficiently) emulate CTV. I'm still very supportive of CTV, I just don't really have any uses I personally understand inside and out aside from vaults... so if others do, they should really post about it on this list and we should resume working on an activation for CTV!
---
From naumenkogs:
> I'm personally not sure batching withdrawals is that compelling... It's a nice-to-have, but I'd think about the benefits dropping this feature would provide.
Having familiarity with a few large-scale custodial operations, I think batching is a really big deal. And if you're going to support multiple deposits to the same vault, no support for batching is going to result in a lot of unnecessary output creation even as a small user if you're, e.g., doing weekly automated deposits from an exchange to a vault you've configured.
Darosior comments:
> On the contrary i think the batching feature is very compelling. The impossibility to batch Unvaults in Revault is a major drawback: it significantly increases the cost of any realistic operation (you need one whole additional transaction per input, and each have likely more than one output). It also potentially increases the cost on the network (you'd likely want some sort of anchor output on each Unvault tx, that you might not spend, so that's 2*n outputs created with n the number of coins spent): we definitely don't want to prevent batching. The ability to batch the recovery transactions (what we called Emergency tx in Revault) is also very compelling but i think your comment was only about batched withdrawals.