Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D3975C002D for ; Thu, 28 Apr 2022 23:51:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id A6D3241C38 for ; Thu, 28 Apr 2022 23:51:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPxldlRZ0vw7 for ; Thu, 28 Apr 2022 23:51:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by smtp4.osuosl.org (Postfix) with ESMTPS id B3B2141C37 for ; Thu, 28 Apr 2022 23:51:49 +0000 (UTC) Received: by mail-ed1-x52d.google.com with SMTP id p18so7248231edr.7 for ; Thu, 28 Apr 2022 16:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ZsDmoA+O08SCzYpiZIhO+qN3P9y7t9yz7vZdnz5szw=; b=UPinj3scF8vm2fLyaHytq1QFLndB4le/DtijiZVyK6xODgj6N9zTprgud+Y16a7Z3l n9+6GMA5GxOCAB0CIncDdVTbJGfQgSH1hGgUidOnTn+SyI5G85ry0IYFE7S8Sh5ZyWXT FX53LkdlsDco1TkgzlPO8/AAIPkZ5tFGQHi0Oy+t0PwwH/U/viYiXBkzJW4obRnWRO2k Cciql5T9CeKS6/1ByYut8ATlYYc/erpGGsA/pc78Z1NCL48ixaI/12ICTv+BetExPN1K xR7MX8yomvJXD3X2ktyjczJNHN91dzibDY1k4ipuq/BOvGXY9w40bJtWa2u9+Qiy0ci8 RgLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5ZsDmoA+O08SCzYpiZIhO+qN3P9y7t9yz7vZdnz5szw=; b=xNXcerdB0X6IuFgbsBeB8fhQSSQroD9lpFCbk530YKSo5heehHnY/oq1xG92tPGabW R+/t+nvRLZkjM/eI+mXMNBqHLJYpJnnkAV6vv1E4mk+M5ebBIfH7JzTK5YyRbJ4NSwPc a8WxFv3ftBEfNSiIoKlw6Vo/fJrNxgKplZp8xBE3BuR7X7jb/h9eBYrVany1ImAuUKgq ZMHRPAHEqneO1kSWJ1VWGqhoH0kAh+onSLdRf7TlBt0k9ZchtMtGo5pjJFAyGXYmNbP1 RhsMoxEMxjKh4xZUu6IiBAx+FeXK1lmWQMYZPR5Z55YBvtvQSCJ5zf1B0eU4QJnGiZ1N 3tuQ== X-Gm-Message-State: AOAM531LWzi3NlAdTD9gY5rD0b0nIMeW50lyxZnyfdK1DanXPkYP21Wn hd6p7WOZRo0jfXrpCnzHcFGTof5QC4y9zIy+rlA= X-Google-Smtp-Source: ABdhPJyY/VmUD7ytDkhKSkoGh4CORhueTaQVczhd09Ge/pOXhbvxkocJzs4GvXScNQ32CKNrfHo2buprKXWsaXmboUU= X-Received: by 2002:a05:6402:330b:b0:425:eded:7cfe with SMTP id e11-20020a056402330b00b00425eded7cfemr22919711eda.357.1651189907716; Thu, 28 Apr 2022 16:51:47 -0700 (PDT) MIME-Version: 1.0 References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org> <48a4546c-85b3-e9ff-83b5-60ba4eae2c76@mattcorallo.com> In-Reply-To: From: Billy Tetrud Date: Thu, 28 Apr 2022 18:51:31 -0500 Message-ID: To: Nadav Ivgi Content-Type: multipart/alternative; boundary="000000000000e7fe1c05ddbf9bb9" X-Mailman-Approved-At: Fri, 29 Apr 2022 07:13:13 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2022 23:51:51 -0000 --000000000000e7fe1c05ddbf9bb9 Content-Type: text/plain; charset="UTF-8" > 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 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 >>> 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 >> > --000000000000e7fe1c05ddbf9bb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 the point of a vault is the ability to keep your primary wallet keys in=C2= =A0highly=C2=A0deep cold storage

I think we'r= e both right. You're also right that there are many possible configurat= ions including the one you mentioned. I can see good reasons to use multisi= g even if both keys are quickly on hand. My only point was that using a wal= let 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=20 get the security of a multisig wallet without having to sign using as=20 many keys.

In my view, the point of a vault is the= ability to keep your primary wallet keys in highly deep cold storag= e (e.g. metal backup only, not loaded on any HW wallets, with geographicall= y distributed shares and a slow cumbersome process for collecting them), wh= ich is made possible because you're not supposed to actually need to us= e these keys, except for the extraordinary (typically once or twice in a li= fetime?) 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 stan= dard hardware wallets you have within reach in your apartment.
So if you have a cold wallet that you anticipate having to acc= ess 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 schem= e 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.

<= div>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-enc= umbered 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
<= br>
Ah I see. Very interesting. Thanks for clarifying.=C2=A0
<= br>@Nadav
> You can have a CTV vault where the hot key sig= ner is a multisig to get the advantages of both.

Y= es, 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=C2=A0get with a multisig wa= llet. 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.=C2=A0

On= Mon, Apr 25, 2022 at 5:28 PM Russell O'Connor <roconnor@blockstream.com> = wrote:
O= n Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tetrud@gmail.com> wrote:
<= /div>
@Russel
> the original MES vault ..=C2=A0commits to the = destination address during unvaulting

I see. Looki= ng 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= .=C2=A0

One possibility is that the intended desti= nation is predetermined and hardcoded. This wouldn't be very useful, an= d also wouldn't be different than how CTV could do it, so I assume that= isn't what you envisioned this doing.

I can i= magine instead that the definition of the pattern could be specified as a n= umber 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 in= putting an intended destination script (corresponding to the intended desti= nation address) which would then be somehow rotated in to the right spot wi= thin the pattern, allowing the pattern to specify the coins eventually reac= hing 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 o= pcode to spend with. It also means that, since the transactor must fully sp= ecify the script, its not possible to take advantage of taproot's=C2=A0= script hiding capabilities (were it to send to a taproot address).

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

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

<= div>No need to rotate anything into place.

I h= ope this makes sense.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000e7fe1c05ddbf9bb9--