> 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 <na...@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 < >> rocon...@blockstream.com> wrote: >> >>> On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tet...@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 >> >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
