path: root/f8/17370240d5ba0ed8dc627f64d0a45d118a258c

Return-Path: <nadav@shesek.info>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 47F12C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 23:14:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 317E8611AE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 23:14:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level: 
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=neutral
 reason="invalid (public key: not available)" header.d=shesek.info
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id OKDbHS_55B73
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 23:14:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com
 [IPv6:2607:f8b0:4864:20::d30])
 by smtp3.osuosl.org (Postfix) with ESMTPS id ADE69611AA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 23:14:15 +0000 (UTC)
Received: by mail-io1-xd30.google.com with SMTP id z18so7717504iob.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 16:14:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shesek.info; s=shesek;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=VcVY+rznj0yd8QOZkMUuU0XyRzY++Dwh3JQyNXusfXc=;
 b=m5fdNeGMDWLGDU0f5QuKFuVmgF1yLRuyUM6rHxJQUwliSbn+48kEFmQw3zF8eqnTyY
 CpL1BxRskgXvKoMJDnBWZE1j7nonI6dumZzN3UZa4B8IhSGq9J2bNvsYMquZxE2xYeAW
 6T2FIjQjZ4lb+3XWIGujEcQW9Hi2dlduL5ydQ=
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=VcVY+rznj0yd8QOZkMUuU0XyRzY++Dwh3JQyNXusfXc=;
 b=qZmu383Aaom2d2dfGOeHY4I0oUDxHY8pxHq/cUhpjiNK6avUgGlDy97crca/4NQ/OS
 DR62jAHmgaDYF0H6SUzIey5H3yQ3i9S5Y9huO192kPoEEDvVcZBaZnKPZK+xQhQHcOkL
 hGlZENim0J2+M2taOjE1BC/r74Y3utlqmkGBZttda9y/a/SF5bWf1tBm9piBUwIbADba
 mgbQdKLYIQyJ4iznJrMye+VSSybr5BjtGQUuQvOB96DJkaSjHe5Bi8pzDCWUfkcPYSxZ
 YKKTg9D9vYhOJlk8+eamnTdrCXhJyC7nFtWRW8VhEqWrsKf51xVOscSvNqsbu//V1nC6
 yz8g==
X-Gm-Message-State: AOAM532f4nXRYUqIYltB1LImGiYOwOFE4rOPzq+WiihVjP4E7w9hH59x
 oo9c9inXv1IMexf8CvEY9etlCHOnO9/jBtsaklMb+g==
X-Google-Smtp-Source: ABdhPJxZzH7hA6UYjToMJuxYPaMod1dgV9BEez7KX6r1ZckO4HbwDkMyqYv5CHm1QSgbQULq7OJP6wFsfx5pfDL+mBw=
X-Received: by 2002:a05:6638:2483:b0:32a:b172:7166 with SMTP id
 x3-20020a056638248300b0032ab1727166mr14865289jat.224.1651187654593; Thu, 28
 Apr 2022 16:14:14 -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>
In-Reply-To: <CAGpPWDZf8aFWMrWp5B6CJdCp-ntq_Gjk+ngZH4yg039P1B0Pgg@mail.gmail.com>
From: Nadav Ivgi <nadav@shesek.info>
Date: Fri, 29 Apr 2022 02:14:03 +0300
Message-ID: <CAGXD5f2CAHr9QM5SuqRLtZZ6m80PyikEO59kx1xNrOfbOuB4LA@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000009c22d805ddbf15b6"
X-Mailman-Approved-At: Fri, 29 Apr 2022 07:13:13 +0000
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:14:17 -0000

--0000000000009c22d805ddbf15b6
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr"><div>&gt; The whole point of a wallet vault is that you ca=
n=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">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid 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 signer is a multisig =
to get the advantages of both.</div><div><br></div><div>Yes, 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 sti=
ll have all the downsides you=C2=A0get with a multisig wallet. The whole po=
int 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:roconnor@blockstream=
.com" target=3D"_blank">roconnor@blockstream.com</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft: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">On Sun, Apr 24, 2022=
 at 7:04 PM Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com" targ=
et=3D"_blank">billy.tetrud@gmail.com</a>&gt; wrote:<br></div><blockquote cl=
ass=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>@Russel<br></div>=
<div>&gt; the original MES vault ..=C2=A0commits to the destination address=
 during unvaulting</div><div><br></div><div>I see. Looking at the MES16 pap=
er, 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 destination is predeterm=
ined and hardcoded. This wouldn&#39;t be very useful, and 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 imagine instead that=
 the definition of the pattern could be specified as a number indicating th=
e number of stack items in the pattern, followed by that number of stack it=
ems. If that&#39;s how it is done, I can see the user inputting an intended=
 destination script (corresponding to the intended destination address) whi=
ch would then be somehow rotated in to the right spot within the pattern, a=
llowing the pattern to specify the coins eventually reaching an address wit=
h that script. However, this could be quite cumbersome, and would require f=
ully specifying the scripts along the covenant pathways leading to a fair a=
mount of information duplication (since scripts must be specified both in t=
he covenant and in spending the subsequent output). Both of these things wo=
uld 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, i=
ts not possible to take advantage of taproot&#39;s=C2=A0script hiding capab=
ilities (were it to send to a taproot address). <br></div></div></blockquot=
e><div><br></div><div>So my understanding is that the COV proposal in MES l=
ets you check that the output&#39;s scriptPubKey matches the corresponding =
script item from the stack, but the script item&#39;s value additionally al=
lows some wildcard values.=C2=A0 In particular, it makes use of the otherwi=
se reserved opcodes OP_PUBKEY, and OP_PUBKEYHASH as wildcards 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 would be third-party =
malleable, but you also have to sign the transaction with the hot wallet ke=
y, which removes the malleability.</div><div><br></div><div>No need to rota=
te anything into place.<br></div><div><br></div><div>I hope this makes sens=
e.</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>

--0000000000009c22d805ddbf15b6--