Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

From: Billy Tetrud <billy.tetrud@gmail•com>
To: Nadav Ivgi <nadav@shesek•info>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
Date: Thu, 28 Apr 2022 18:51:31 -0500	[thread overview]
Message-ID: <CAGpPWDaZVysHd1_GA4V3bQNis272mdTPRDB7EtZ0rGVVxgJ=zA@mail.gmail.com> (raw)
In-Reply-To: <CAGXD5f2CAHr9QM5SuqRLtZZ6m80PyikEO59kx1xNrOfbOuB4LA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5745 bytes --]

>  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
>>
>

[-- Attachment #2: Type: text/html, Size: 7394 bytes --]