path: root/17/7686b1ce74ab57b69d753f95e7b3270acb1da4

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 A1A31C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 Apr 2022 23:04:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 8125A4090B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 Apr 2022 23:04:12 +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 EtsCHy5sv6kB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 Apr 2022 23:04:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [IPv6:2a00:1450:4864:20::62d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 386C9408CC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 Apr 2022 23:04:10 +0000 (UTC)
Received: by mail-ej1-x62d.google.com with SMTP id g6so3580332ejw.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 Apr 2022 16:04:10 -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=iEWsqyLf4+k0Wm2frrXi2kRdclMZ93723XMD+h1hW6c=;
 b=HGM5TVe2I7aZHOttr71jxlsGOXK3BMc9adehvLRLlVQAsYkh/0LbDsKzMmVXwJ0M2B
 MUUVvADI+MtcsD9uTlAOFA4UQ9xAguydxUZo+RBo+kIqBtQqbC/xDwPhlAEzuQXUHC8x
 dv4yjpO0uIifsFSNDZ6iwnn0s1cCsP/pclgwmV1PpxerNGL8HG0AKFvzAPC2YAjPo5xn
 KdS3RZC6I/V3D2X2b2HsonGJg7WIt5S9kj1Su8uMaZiinCR+dm1Ejl3j+KOq94+/4Hxu
 qp/jD+7WjPK8qNTC9fP/ORBoVDft6NwWFOzPjD4YB+/lN1Sdc64aUEsY+2A7vvkkNqP+
 DrVg==
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=iEWsqyLf4+k0Wm2frrXi2kRdclMZ93723XMD+h1hW6c=;
 b=6dcP0XRBfhMGTl0eMCjXZ0mNeLbnodxoMpOJYadK3nuiCvRuFDfbpjXo8OFzXJmf46
 yvE5/Cxz4sRWHhFfYHWHy9EvUg3npRl9CLxF5Yl78kwDUJB4AxgBL5BaCU5Xon1v4jqD
 2S61z3gbQi1IMzCFnRx070WiEx+ED2to6tVuKhvjEP0LDGlKpG/VRKB1BSoCLyFz1NXp
 YzopbNjyuyk7VoVgnXJkbyNt0KnNIdwfJyWxEfGzZARBTk0pSFQLN9AITr7rjELLZeFx
 VxfBk68N0/J4z9Ox+YAZaPLPcOz0czLgRwhBUb8QQHxraE6c3jzcwXTxk6VWoEec+c5s
 2ZBQ==
X-Gm-Message-State: AOAM530GwkoLm9qkAXJmnpUV0Bq+kKZIqct9p68QiLsHn3sRosYlqw+O
 rlfHpbEL9B3izquWCtdo28CdUUqkbudzLxEfwDw=
X-Google-Smtp-Source: ABdhPJyN3XGm2QzIM7HTzsnL2Jm/AbS/RxsLTI3h2+MZCQauVik07UAdpLk7sn87NLkyI3roAJCuZXX0RYmAC+rNMDw=
X-Received: by 2002:a17:907:3d91:b0:6df:a01c:f7cd with SMTP id
 he17-20020a1709073d9100b006dfa01cf7cdmr13802973ejc.255.1650841448065; Sun, 24
 Apr 2022 16:04:08 -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>
In-Reply-To: <CAMZUoKniYvmtYXOOOqpDGyaEyzG5DObwbFQhvaYkndSnJUmvkg@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 24 Apr 2022 18:03:52 -0500
Message-ID: <CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1A@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000017acb105dd6e7a8f"
X-Mailman-Approved-At: Mon, 25 Apr 2022 10:36:12 +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: Sun, 24 Apr 2022 23:04:12 -0000

--00000000000017acb105dd6e7a8f
Content-Type: text/plain; charset="UTF-8"

@Matt
>  both of which are somewhat frustrating limitations, but not security
limitations, only practical ones.

So I think the first limitation you mentioned (that if your hot wallet's
key gets stolen you need) can be legitimately considered a security
limitation. Not because you need to rotate your keys, but because you might
*not know* your hot wallet key has been stolen. If you unvault an output to
your hot wallet, the thief could be lying in wait, ready to steal those
funds upon them landing. At that point, you would then know your hot wallet
key was compromised and could rotate your vault keys in order to prevent
further theft. However, the fact that there is a clear theft vulnerability
is something I would say should be considered a "security limitation".

As you mentioned, this is of course also a security limitation of a hot
wallet, so this setup definitely has a lot of advantages over a simple hot
wallet. However, if you compare it against a multisig wallet (eg 2 of 3),
you can see that while theft of a single key would never result in any
theft in that setup, it could in a CTV vault. The other trade offs there
are ones of practicality and convenience.

This isn't to say a CTV vault wouldn't be useful. Just that it has
significant trade offs.

@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).

However, my assumptions might be incorrect. If you think OP_COV would be a
useful opcode, I would encourage you to write up a complete specification.

> What ways can we build a secured vault that commits to the destination
address?

Some kind of passed-through state allows doing this. With OP_COV (if my
assumptions above are correct), the intended destination can be passed
through the output script pattern(s). With my own proposed
op_pushoutputstack
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>,
state is passed as an attachment on the output more directly. Curious what
you think about that proposal.

> Are there elegant ways of building secure vaults by using CTV plus
something else.

Since CTV predefines all the transactions that can happen under its
control, passed state like this can't help because any dynamic state would
change the template and render the CTV transaction invalid. I don't see any
way of solving this problem for CTV.

I'm curious how you think op_cat could enable this with CTV (other than the
cat+schnorr tricks that don't require CTV at all).



On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Okay, Matt explained to me the intended application of CTV vaults off
> list, so I have a better understanding now.
>
> The CTV vault scheme is designed as an improvement over the traditional
> management of hot-wallets and cold-wallets.  The CTV vault is logically on
> the "cold-side" and lets funds be sent from the "cold" side to *one's own*
> the hot wallet after the unvaulting delay.  In this case, the hot wallet
> funds are always at risk, so it isn't unexpected that those funds could be
> stolen.  After all, that is how hot wallets are today.  The advantage is
> that funds can be moved from the "cold" side without needing to dig out the
> cold keys.
>
> The MES vault scheme applies to a different scenario.  In the MES case it
> is the hot funds are inside the vault, and it is the hot key that unvaults
> the funds and sends them to *customer's addresses* after a delay.  If the
> hot-key is used in any unauthorised way, then funds can be sent to the
> address of the cold key (the MES vault actually does something fancy in
> case of recovery, but it could be adapted to simply send funds to a cold
> wallet).
>
> The MES vault lie somewhere between "better" and "different" when compared
> to the CTV vault.  If one is unwilling to use the MES vault on the hot side
> and have every withdrawl vetted, then, while you could use the MES design
> on the cold side like the CTV vault, it wouldn't really offer you any
> advantages over a CTV vault.  However, if you are interested in managing
> all your payments through a vault (as I've been imagining) then the CTV
> vault comes across as ineffective when compared to an MES style vault.
>
> On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <lf-lists@mattcorallo.com>
> wrote:
>
>> Still trying to make sure I understand this concern, let me know if I get
>> this all wrong.
>>
>> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
>> > It's not the attackers *only choice to succeed*.  If an attacker steals
>> the hot key, then they have
>> > the option to simply wait for the user to unvault their funds of their
>> own accord and then race /
>> > outspend the users transaction with their own.  Indeed, this is what we
>> expect would happen in the
>> > dark forest.
>>
>> Right, a key security assumption of the CTV-based vaults would be that
>> you MUST NOT EVER withdraw
>> more in one go than your hot wallet risk tolerance, but given that your
>> attack isn't any worse than
>> simply stealing the hot wallet key immediately after a withdraw.
>>
>> It does have the drawback that if you ever get a hot wallet key stole you
>> have to rotate all of your
>> CTV outputs and your CTV outputs must never be any larger than your hot
>> wallet risk tolerance
>> amount, both of which are somewhat frustrating limitations, but not
>> security limitations, only
>> practical ones.
>>
>> > And that's not even mentioning the issues already noted by the document
>> regarding fee management,
>> > which would likely also benefit from a less constrained design for
>> covenants.
>>
>> Of course I've always been in favor of a less constrained covenants
>> design from day one for ten
>> reasons, but that's a whole other rabbit hole :)
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>@Matt<br></div>&gt;=C2=A0

both of which are somewhat frustrating limitations, but not security limita=
tions, only practical ones.<div><br></div><div>So I think the first limitat=
ion you mentioned (that if your hot wallet&#39;s key gets stolen you need) =
can be legitimately considered a security limitation. Not because you need =
to rotate=C2=A0your keys, but because you might *not know* your hot wallet =
key has been stolen. If you unvault an output to your hot wallet, the thief=
=C2=A0could be lying in wait, ready to steal those funds upon them landing.=
 At that point, you would then know your hot wallet key was compromised and=
 could rotate your vault keys in order to prevent further theft. However, t=
he fact that there is a clear theft vulnerability is something I would say =
should be considered a &quot;security limitation&quot;.=C2=A0</div><div><br=
></div><div>As you mentioned, this is of course also a security limitation =
of a hot wallet, so this setup definitely has a lot of advantages over a si=
mple hot wallet. However, if you compare it against a multisig wallet (eg 2=
 of 3), you can see that while theft of a single key would never result in =
any theft in that setup, it could in a CTV vault. The other trade offs ther=
e are ones of practicality and convenience.</div><div><br></div><div>This i=
sn&#39;t to say a CTV vault wouldn&#39;t be useful. Just that it has signif=
icant trade offs.=C2=A0</div><div><br></div><div>@Russel<br></div><div>&gt;=
 the original MES vault ..=C2=A0commits to the destination address during u=
nvaulting</div><div><br></div><div>I see. Looking at the MES16 paper, OP_CO=
V 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 predetermined and =
hardcoded. This wouldn&#39;t be very useful, and also wouldn&#39;t be diffe=
rent than how CTV could do it, so I assume that isn&#39;t what you envision=
ed this doing.</div><div><br></div><div>I can imagine instead that the defi=
nition 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 t=
hat&#39;s how it is done, I can see the user inputting an intended destinat=
ion script (corresponding to the intended destination address) which would =
then be somehow rotated in to the right spot within the pattern, allowing t=
he pattern to specify the coins eventually reaching an address with that sc=
ript. However, this could be quite cumbersome, and would require fully spec=
ifying the scripts along the covenant pathways leading to a fair amount of =
information duplication (since scripts must be specified both in the covena=
nt 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 po=
ssible to take advantage of taproot&#39;s=C2=A0script hiding capabilities (=
were it to send to a taproot address).=C2=A0</div><div><br></div><div>Howev=
er, my assumptions might be incorrect. If you think OP_COV would be a usefu=
l opcode, I would encourage you to write up a complete specification.</div>=
<div><br></div><div>&gt; What ways can we build a secured vault that commit=
s to the destination address?<br></div><div><br></div><div>Some kind of pas=
sed-through state allows doing this. With OP_COV (if my assumptions above a=
re correct), the intended destination can be passed through the output scri=
pt pattern(s). With my own proposed=C2=A0<a href=3D"https://github.com/fres=
heneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md" =
target=3D"_blank">op_pushoutputstack</a>, state is passed as an attachment =
on the output more directly. Curious what you think about that proposal.<br=
></div><div><br></div><div>&gt; Are there elegant ways of building secure v=
aults by using CTV plus something else.</div><div><br></div><div>Since CTV =
predefines all the transactions that can happen under its control, passed s=
tate like this can&#39;t help because any dynamic state would change the te=
mplate and render the CTV transaction invalid. I don&#39;t see any way of s=
olving this problem for CTV.=C2=A0=C2=A0</div><div><br></div><div>I&#39;m c=
urious how you think op_cat could enable this with CTV (other than the cat+=
schnorr tricks that don&#39;t require CTV at all).</div><div><br></div><div=
><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Sat, Apr 23, 2022 at 2:31 PM Russell O&#39;Connor via bitcoin=
-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blo=
ckquote 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>Okay, M=
att explained to me the intended application of CTV vaults off list, so I h=
ave a better understanding now.</div><div><br></div><div>The CTV vault sche=
me is designed as an improvement over the traditional management of hot-wal=
lets and cold-wallets.=C2=A0 The CTV vault is logically on the &quot;cold-s=
ide&quot; and lets funds be sent from the &quot;cold&quot; side to *one&#39=
;s own* the hot wallet after the unvaulting delay.=C2=A0 In this case, the =
hot wallet funds are always at risk, so it isn&#39;t unexpected that those =
funds could be stolen.=C2=A0 After all, that is how hot wallets are today.=
=C2=A0 The advantage is that funds can be moved from the &quot;cold&quot; s=
ide without needing to dig out the cold keys.<br></div><div><br></div><div>=
The MES vault scheme applies to a different scenario.=C2=A0 In the MES case=
 it is the hot funds are inside the vault, and it is the hot key that unvau=
lts the funds and sends them to *customer&#39;s addresses* after a delay.=
=C2=A0 If the hot-key is used in any unauthorised way, then funds can be se=
nt to the address of the cold key (the MES vault actually does something fa=
ncy in case of recovery, but it could be adapted to simply send funds to a =
cold wallet).</div><div><br></div><div>The MES vault lie somewhere between =
&quot;better&quot; and &quot;different&quot; when compared to the CTV vault=
.=C2=A0 If one is unwilling to use the MES vault on the hot side and have e=
very withdrawl vetted, then, while you could use the MES design on the cold=
 side like the CTV vault, it wouldn&#39;t really offer you any advantages o=
ver a CTV vault.=C2=A0 However, if you are interested in managing all your =
payments through a vault (as I&#39;ve been imagining) then the CTV vault co=
mes across as ineffective when compared to an MES style vault.<br></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, A=
pr 23, 2022 at 2:24 PM Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcora=
llo.com" target=3D"_blank">lf-lists@mattcorallo.com</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">Still trying to make sur=
e I understand this concern, let me know if I get this all wrong.<br>
<br>
On 4/22/22 10:25 AM, Russell O&#39;Connor via bitcoin-dev wrote:<br>
&gt; It&#39;s not the attackers *only choice to succeed*.=C2=A0 If an attac=
ker steals the hot key, then they have <br>
&gt; the option to simply wait for the user to unvault their funds of their=
 own accord and then race / <br>
&gt; outspend the users transaction with their own.=C2=A0 Indeed, this is w=
hat we expect would happen in the <br>
&gt; dark forest.<br>
<br>
Right, a key security assumption of the CTV-based vaults would be that you =
MUST NOT EVER withdraw <br>
more in one go than your hot wallet risk tolerance, but given that your att=
ack isn&#39;t any worse than <br>
simply stealing the hot wallet key immediately after a withdraw.<br>
<br>
It does have the drawback that if you ever get a hot wallet key stole you h=
ave to rotate all of your <br>
CTV outputs and your CTV outputs must never be any larger than your hot wal=
let risk tolerance <br>
amount, both of which are somewhat frustrating limitations, but not securit=
y limitations, only <br>
practical ones.<br>
<br>
&gt; And that&#39;s not even mentioning the issues already noted by the doc=
ument regarding fee management, <br>
&gt; which would likely also benefit from a less constrained design for cov=
enants.<br>
<br>
Of course I&#39;ve always been in favor of a less constrained covenants des=
ign from day one for ten <br>
reasons, but that&#39;s a whole other rabbit hole :)<br>
</blockquote></div></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>

--00000000000017acb105dd6e7a8f--