path: root/af/ac515ae927121155d87465c40ef33e821cd112

Return-Path: <roconnor@blockstream.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 326CFC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 23 Apr 2022 14:02:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 1987741A55
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 23 Apr 2022 14:02:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 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=blockstream-com.20210112.gappssmtp.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 G3uKUyPRsGjQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 23 Apr 2022 14:02:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com
 [IPv6:2607:f8b0:4864:20::72e])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 76FDE41A47
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 23 Apr 2022 14:02:49 +0000 (UTC)
Received: by mail-qk1-x72e.google.com with SMTP id a186so7806731qkc.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 23 Apr 2022 07:02:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=BjjXE4zSCw2fuuutzl6D6b8VOOyZz7K8lw0na2DA+ug=;
 b=mnXb9hXtSEt3u+nzuixyVNTpeVuvB9OoXpc3nuZIs33eE4Rfw2NtLPRBXhyvG9UojF
 0CGFGYP85aQoXzZvzI7l9vd7kGIFJEncBC6kvuZFD69lu7U74POU8RQDel49h0ZwYc9x
 kFTRYOb1bl7EirvqFPUGd1ryvt/cg1KU5NiHLz1uJTAR9ZnSURZKqzbYOKxm7YlSnXeW
 j98XfKa8UQlZZrEPceDIK0eHugIDGZSew2rJNjziOu5qOR7xYfN7fjuIMC+CZ6VztmYv
 STAdcYf5yyTO7YQd+GmH1qZj4IRemd80o07JJMdTbIZAlz90qaepyUAmcxESqlPPxreQ
 aRlg==
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;
 bh=BjjXE4zSCw2fuuutzl6D6b8VOOyZz7K8lw0na2DA+ug=;
 b=Ol5PmnN6nrjBVce0wnzPEFBdQFHjiLpgyCcuyRnKhYj9FwPcuezieARlDwY+gz4dZ3
 t90LCJWgAw8jeeXmOjiqz3hSjBrFP3SeiQPeG+40CShroY+0lhDLS9+aoah2/dCbTVU8
 CuJl5mXjumB4H63YqO4PwMY/0hK8S800Pl5dvLeLDxUjSXldWujXkAOjou9w9JAokT86
 0Y/nlSHTHzKwBP6GGDTejs5ol37AKXuUqQFo+3UaR9Ix5x3hqiZdJzE/0ebe/7+szsYf
 9iP+CYqIjh/0PaM6j78GU/oohmOEhJ35PSU0GUn7HTBc2+DF/yWYWwxrEsIcY/d+Sohh
 IHXA==
X-Gm-Message-State: AOAM530+TAfIvHhVW4A/Kf6hRbexuXLlhw53R4NwJeZV+gUVZV4aMAN2
 iKGx+vw+BarF5+o77qaSq67UcfxvXMQW9J4D63G3mElrsnB48A==
X-Google-Smtp-Source: ABdhPJwkJZ8rVfWoN2Vw0l8Xdv5XSfWk/756WV3T63ImrkuH8zdjfVn3cpZg7FMRLQtVLBOqTf1Kmwu+vPgFMaYTtac=
X-Received: by 2002:a05:620a:12c3:b0:69e:84bb:b470 with SMTP id
 e3-20020a05620a12c300b0069e84bbb470mr5505778qkl.180.1650722568041; Sat, 23
 Apr 2022 07:02:48 -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>
 <CAGpPWDaSJu-B5VvMxrssag+08m53EaO0TW0P+KusJ8DL98kB7g@mail.gmail.com>
In-Reply-To: <CAGpPWDaSJu-B5VvMxrssag+08m53EaO0TW0P+KusJ8DL98kB7g@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Sat, 23 Apr 2022 10:02:36 -0400
Message-ID: <CAMZUoKnVTVK=GDhTbsBVa0j82TCvr4YrwjnEm+o6EKueMR7ofQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004a8e6805dd52cc8d"
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: Sat, 23 Apr 2022 14:02:51 -0000

--0000000000004a8e6805dd52cc8d
Content-Type: text/plain; charset="UTF-8"

On Sat, Apr 23, 2022 at 12:56 AM Billy Tetrud <billy.tetrud@gmail.com>
wrote:

> > If an attacker steals the hot key, then they have the option to simply
> wait for the user to unvault their funds
>
> This is definitely true. Its kind of a problem with most vault proposals.
> Its one of the primary reasons I designed an alternative proposal
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults>. The
> OP_BEFOREBLOCKVERIFY opcode I proposed solves this security hole by
> automatically swapping control of the UTXO over to the intended recipient
> after a timeout. Alternatively, if OP_BBV weren't available, OP_POS in
> conjunction with OP_CD could encode things such that the transaction
> with the hot key could only spend to the intended recipient.
>
> I'm curious if there are any other covenant proposals that have a solution
> to that problem. I'm not aware of any that do other than my proposal.
>

As I noted, the original MES vault
https://fc16.ifca.ai/bitcoin/papers/MES16.pdf, commits to the destination
address during unvaulting.  Their proposal uses CheckOutputVerify that
checks if a given output has a given amount and a given scriptPubKey.  (The
MES vault then goes on to add a PATTERN parameter to OP_COV's scriptPubKey
parameter in order to make a recursive vault, but that is used to deter
cold-key theft, not hot-key theft).

Our paper https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
impelments the MES vault in Elements (alpha) using CAT and
CHECKSIGFROMSTACK.  While I wouldn't necessarily call it a covenant
proposal, rather it is an observation that these opcodes happen to be
adequate for the task.

With such a big security caveat, I really don't find CTV vaults a
compelling example of using CTV.  Sure, if CTV happens to exist, by all
means do whatever you like.  But if anything, the CTV vault scheme instead
illustrates BlueMatt's point that we aren't really finished with covenant
research design yet:

Q: What ways can we build a secured vault that commits to the destination
address?
Q: Are there elegant ways of building secure vaults by using CTV plus
something else.  Presumably CAT + CTV would be enough, though maybe some
people are concerned that CAT might enable recursive covenants (if people
aren't willing to have even CAT, I don't see how we will ever really have
programmable money).

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Sat, Apr 23, 2022 at 12:56 AM Billy Tetrud &lt;<a href=3D"mailto:=
billy.tetrud@gmail.com">billy.tetrud@gmail.com</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>&gt; If=
 an attacker steals the hot key, then they have the option to simply wait f=
or the user to unvault their funds</div><div><br></div>This is definitely t=
rue. Its kind of a problem with=C2=A0most vault proposals. Its one of the p=
rimary reasons I designed <a href=3D"https://github.com/fresheneesz/bip-eff=
icient-bitcoin-vaults" target=3D"_blank">an alternative proposal</a>. The O=
P_BEFOREBLOCKVERIFY opcode I proposed solves this security hole by automati=
cally swapping control of the UTXO over to the intended recipient after a t=
imeout. Alternatively, if OP_BBV weren&#39;t available, OP_POS in conjuncti=
on with OP_CD could encode things such that the transaction with=C2=A0the h=
ot key could only spend to the intended recipient.=C2=A0<div><br></div><div=
>I&#39;m curious if there are any other covenant proposals that have a solu=
tion to that problem. I&#39;m not aware of any that do other than my propos=
al. <br></div></div></blockquote><div><br></div><div>As I noted, the origin=
al MES vault <a href=3D"https://fc16.ifca.ai/bitcoin/papers/MES16.pdf">http=
s://fc16.ifca.ai/bitcoin/papers/MES16.pdf</a>, commits to the destination a=
ddress during unvaulting.=C2=A0 Their proposal uses CheckOutputVerify that =
checks if a given output has a given amount and a given scriptPubKey.=C2=A0=
 (The MES vault then goes on to add a PATTERN parameter to OP_COV&#39;s scr=
iptPubKey parameter in order to make a recursive vault, but that is used to=
 deter cold-key theft, not hot-key theft).</div><div><br></div><div>Our pap=
er <a href=3D"https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf">ht=
tps://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf</a> impelments the =
MES vault in Elements (alpha) using CAT and CHECKSIGFROMSTACK.=C2=A0 While =
I wouldn&#39;t necessarily call it a covenant proposal, rather it is an obs=
ervation that these opcodes happen to be adequate for the task.</div><div><=
br></div><div>With such a big security caveat, I really don&#39;t find CTV =
vaults a compelling example of using CTV.=C2=A0 Sure, if CTV happens to exi=
st, by all means do whatever you like.=C2=A0 But if anything, the CTV vault=
 scheme instead illustrates BlueMatt&#39;s point that we aren&#39;t really =
finished with covenant research design yet:</div><div><br></div><div>Q: Wha=
t ways can we build a secured vault that commits to the destination address=
?</div><div>Q: Are there elegant ways of building secure vaults by using CT=
V plus something else.=C2=A0 Presumably CAT=C2=A0+ CTV would be enough, tho=
ugh maybe some people are concerned that CAT might enable recursive covenan=
ts (if people aren&#39;t willing to have even CAT, I don&#39;t see how we w=
ill ever really have programmable money).<br></div><div><br></div></div></d=
iv>

--0000000000004a8e6805dd52cc8d--