>  the point of a vault is the ability to keep your primary wallet keys in highly deep cold storage

I think we're both right. You're also right that there are many possible configurations including the one you mentioned. I can see good reasons to use multisig even if both keys are quickly on hand. My only point was that using a wallet vault that unvaults to a multisig isn't a best of both worlds, but rather has different trade offs. Sounds like we agree.

On Thu, Apr 28, 2022 at 6:14 PM Nadav Ivgi <nadav@shesek.info> wrote:
> The whole point of a wallet vault is that you can get the security of a multisig wallet without having to sign using as many keys.

In my view, the point of a vault is the ability to keep your primary wallet keys in highly deep cold storage (e.g. metal backup only, not loaded on any HW wallets, with geographically distributed shares and a slow cumbersome process for collecting them), which is made possible because you're not supposed to actually need to use these keys, except for the extraordinary (typically once or twice in a lifetime?) circumstances of theft.

The user can then use a warmer model for the keys they use more frequently for the covenant-encumbered two-step spending. But these warmer keys can themselves also be cold and/or multi-sig, yet more accessible. For example, a 2-of-2 with standard hardware wallets you have within reach in your apartment.

So if you have a cold wallet that you anticipate having to access once every, say, 2-3 months, no matter what scheme you currently use to secure it, you can improve your overall security by using that same scheme for securing the covenant-encumbered keys, then use a colder more secure scheme for your primary keys under the assumption that you'll only have to access them at most once every several years.

IIUC what you were describing is that you can use your regular multisig scheme for the primary cold wallet keys, and a 1-of-1 for the covenant-encumbered keys (which can even be hot on your phone etc).

Both approaches are valid, one gets you more security while the other gets you more convenience. And there is of course a whole range of options that can be chosen in between that gets you some of both.

shesek

On Wed, Apr 27, 2022 at 11:09 AM Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
@Russell
> OP_PUBKEY, and OP_PUBKEYHASH as wildcards

Ah I see. Very interesting. Thanks for clarifying. 

@Nadav
> You can have a CTV vault where the hot key signer is a multisig to get the advantages of both.

Yes, you can create a CTV vault setup where you unvault to a multisig wallet, but you don't get the advantages of both. Rather you get none of the advantages and still have all the downsides you get with a multisig wallet. The whole point of a wallet vault is that you can get the security of a multisig wallet without having to sign using as many keys. 

On Mon, Apr 25, 2022 at 5:28 PM Russell O'Connor <roconnor@blockstream.com> wrote:
On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tetrud@gmail.com> wrote:
@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).

So my understanding is that the COV proposal in MES lets you check that the output's scriptPubKey matches the corresponding script item from the stack, but the script item's value additionally allows some wildcard values.  In particular, it makes use of the otherwise reserved opcodes OP_PUBKEY, and OP_PUBKEYHASH as wildcards representing any, let's say, 32-byte or 20-byte push value.

If you just used COV by itself, then these wildcards would be third-party malleable, but you also have to sign the transaction with the hot wallet key, which removes the malleability.

No need to rotate anything into place.

I hope this makes sense.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev