path: root/d9/60d6bfe2f274990d3e7f7afea9bc4354f1776d

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D3975C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 23:51:49 +0000 (UTC)
Received: by mail-ed1-x52d.google.com with SMTP id p18so7248231edr.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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>
 <d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
 <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
 <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
 <CAPfvXfJe6YHViquT8i+Kq2QUjZDZyUq24nKkJd2a6dYKgygxNQ@mail.gmail.com>
 <CAMZUoK=GONdGwj34PcqjV5sFJBg+XqiSOHFk4aQoTgy00YFG=Q@mail.gmail.com>
 <48a4546c-85b3-e9ff-83b5-60ba4eae2c76@mattcorallo.com>
 <CAMZUoKniYvmtYXOOOqpDGyaEyzG5DObwbFQhvaYkndSnJUmvkg@mail.gmail.com>
 <CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1A@mail.gmail.com>
 <CAMZUoKnmvjOXq8NY_DnBQnRp6snxZ7hDCF1XQCndwCcp1rBO3Q@mail.gmail.com>
 <CAGpPWDZf8aFWMrWp5B6CJdCp-ntq_Gjk+ngZH4yg039P1B0Pgg@mail.gmail.com>
 <CAGXD5f2CAHr9QM5SuqRLtZZ6m80PyikEO59kx1xNrOfbOuB4LA@mail.gmail.com>
In-Reply-To: <CAGXD5f2CAHr9QM5SuqRLtZZ6m80PyikEO59kx1xNrOfbOuB4LA@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 28 Apr 2022 18:51:31 -0500
Message-ID: <CAGpPWDaZVysHd1_GA4V3bQNis272mdTPRDB7EtZ0rGVVxgJ=zA@mail.gmail.com>
To: Nadav Ivgi <nadav@shesek.info>
Content-Type: multipart/alternative; boundary="000000000000e7fe1c05ddbf9bb9"
X-Mailman-Approved-At: Fri, 29 Apr 2022 07:13:13 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
>>
>

--000000000000e7fe1c05ddbf9bb9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0

the point of a vault is the ability to keep your primary wallet keys in=C2=
=A0<i>highly</i>=C2=A0deep cold storage<div><br></div><div>I think we&#39;r=
e both right. You&#39;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&#39;t a best of both worlds, but =
rather has different trade offs. Sounds like we agree.</div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 28,=
 2022 at 6:14 PM Nadav Ivgi &lt;<a href=3D"mailto:nadav@shesek.info">nadav@=
shesek.info</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div>&gt; 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.</div><div><br></div><div>In my view, the point of a vault is the=
 ability to keep your primary wallet keys in <i>highly</i> 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&#39;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.</div><div><br></div><div>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.</div><div><b=
r></div><div>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&#39;ll only have=
 to access them at most once every several years.<br></div><div><br></div><=
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).</div><div><br></div=
><div>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.<br></div><div><b=
r></div><div>shesek<br></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Apr 27, 2022 at 11:09 AM Billy Tetrud=
 via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
@Russell<br><div>&gt; OP_PUBKEY, and OP_PUBKEYHASH as wildcards</div><div><=
br></div><div>Ah I see. Very interesting. Thanks for clarifying.=C2=A0<br><=
br>@Nadav<br></div><div>&gt; You can have a CTV vault where the hot key sig=
ner is a multisig to get the advantages of both.</div><div><br></div><div>Y=
es, you can create a CTV vault setup where you unvault to a multisig wallet=
, but you don&#39;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</div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Mon, Apr 25, 2022 at 5:28 PM Russell O&#39;Connor &lt;<a href=3D"mailto:ro=
connor@blockstream.com" target=3D"_blank">roconnor@blockstream.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud &lt;<a href=3D"mailto:billy.tet=
rud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v>@Russel<br></div><div>&gt; the original MES vault ..=C2=A0commits to the =
destination address during unvaulting</div><div><br></div><div>I see. Looki=
ng at the MES16 paper, OP_COV isn&#39;t described clearly enough for me to =
understand that it does that. However, I can imagine how it *might* do that=
.=C2=A0</div><div><br></div><div>One possibility is that the intended desti=
nation is predetermined and hardcoded. This wouldn&#39;t be very useful, an=
d also wouldn&#39;t be different than how CTV could do it, so I assume that=
 isn&#39;t what you envisioned this doing.</div><div><br></div><div>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&#39;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&#39;s=C2=A0=
script hiding capabilities (were it to send to a taproot address). <br></di=
v></div></blockquote><div><br></div><div>So my understanding is that the CO=
V proposal in MES lets you check that the output&#39;s scriptPubKey matches=
 the corresponding script item from the stack, but the script item&#39;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&#39;s say, 32-byte or 20-byte push value.</div>=
<div><br></div><div>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><div><br></div><=
div>No need to rotate anything into place.<br></div><div><br></div><div>I h=
ope this makes sense.</div></div></div>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--000000000000e7fe1c05ddbf9bb9--