@Matt
>
both of which are somewhat frustrating limitations, but not security limitations, only practical ones.
So I think the first limitation you mentioned (that if your hot wallet's key gets stolen you need) can be legitimately considered a security limitation. Not because you need to rotate your keys, but because you might *not know* your hot wallet key has been stolen. If you unvault an output to your hot wallet, the thief could be lying in wait, ready to steal those funds upon them landing. At that point, you would then know your hot wallet key was compromised and could rotate your vault keys in order to prevent further theft. However, the fact that there is a clear theft vulnerability is something I would say should be considered a "security limitation".
As you mentioned, this is of course also a security limitation of a hot wallet, so this setup definitely has a lot of advantages over a simple hot wallet. However, if you compare it against a multisig wallet (eg 2 of 3), you can see that while theft of a single key would never result in any theft in that setup, it could in a CTV vault. The other trade offs there are ones of practicality and convenience.
This isn't to say a CTV vault wouldn't be useful. Just that it has significant trade offs.
@Russel
> the original MES vault .. commits to the destination address during unvaulting
I see. Looking at the MES16 paper, OP_COV isn't described clearly enough for me to understand that it does that. However, I can imagine how it *might* do that.
One possibility is that the intended destination is predetermined and hardcoded. This wouldn't be very useful, and also wouldn't be different than how CTV could do it, so I assume that isn't what you envisioned this doing.
I can imagine instead that the definition of the pattern could be specified as a number indicating the number of stack items in the pattern, followed by that number of stack items. If that's how it is done, I can see the user inputting an intended destination script (corresponding to the intended destination address) which would then be somehow rotated in to the right spot within the pattern, allowing the pattern to specify the coins eventually reaching an address with that script. However, this could be quite cumbersome, and would require fully specifying the scripts along the covenant pathways leading to a fair amount of information duplication (since scripts must be specified both in the covenant and in spending the subsequent output). Both of these things would seem to make OP_COV in practice quite an expensive opcode to spend with. It also means that, since the transactor must fully specify the script, its not possible to take advantage of taproot's script hiding capabilities (were it to send to a taproot address).
However, my assumptions might be incorrect. If you think OP_COV would be a useful opcode, I would encourage you to write up a complete specification.
> What ways can we build a secured vault that commits to the destination address?
Some kind of passed-through state allows doing this. With OP_COV (if my assumptions above are correct), the intended destination can be passed through the output script pattern(s). With my own proposed
op_pushoutputstack, state is passed as an attachment on the output more directly. Curious what you think about that proposal.
> Are there elegant ways of building secure vaults by using CTV plus something else.
Since CTV predefines all the transactions that can happen under its control, passed state like this can't help because any dynamic state would change the template and render the CTV transaction invalid. I don't see any way of solving this problem for CTV.
I'm curious how you think op_cat could enable this with CTV (other than the cat+schnorr tricks that don't require CTV at all).