path: root/32/b1de682e0b6588f77ce9684b57c7e8e85834be

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C3574C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 23 Apr 2022 04:56:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 9B2AD60F60
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 23 Apr 2022 04:56:20 +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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 fP3H--BMHqrl
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 23 Apr 2022 04:56:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [IPv6:2a00:1450:4864:20::636])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 4186060F4C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 23 Apr 2022 04:56:19 +0000 (UTC)
Received: by mail-ej1-x636.google.com with SMTP id ks6so19974583ejb.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 21:56:19 -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;
 bh=wxHOCF3kvw5+/nTzUHw27154SsiVBxyerbY2ZK7xq+o=;
 b=FH1R5/bmRa5M3PfeJOc2cWsdJX3kQ9ueXvZRh3Qqo+Mdw/5LnOkCWHlwhQaL1tBFGj
 DLM2lXHOYyGCGKl0VeQRRWWMLPzDXEVP7iDxlzUGOVwK4kjR2gjqkic8almvbZVNtKuc
 efRjsiKXK/Hq6u/LYlyBA/E6YwWHtMHF9tluAo0JpHTNadHa/khZntTKfLt5UYEhB73e
 Z/HPBHRnNgA1xt6FnRsCRjVHtYC8ioX00ozchNw+83TPSulxylCtbriBwbVdsVThyx4K
 b3KDQwMS8RveTdQlYOBEwaPrMlK94RrgEteRYJyUs1P+SLpHZ7uK34VsS/I1u0XsHcPC
 F4kg==
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=wxHOCF3kvw5+/nTzUHw27154SsiVBxyerbY2ZK7xq+o=;
 b=x9XX6DhLg+0g7vtG5FGq8gbRMdp/5G/nNXVNc3IE56oqO2Jz36MhbOmu++PGN4wsrI
 k37SZN/YwpnUS1eYcUq5WJWXXbSSmfDulpQSdCC7pTPGj3WdyIWzlJ4GW9whZOWF4a60
 JrWYAMRuI2PSurHn/OQqXZFqI8yFXktvKYo3vS3vaMn0Yc2YLeD5QO0GClboPhj1HMOP
 qAUPOXjBcgYvgIMLm8LssjeSDAUyUskkrcNeTtgLS2LY2/8saUUKxswDFKbh43EpgkW1
 /LbqMZYN1crpPQHsB34023jlvCsKcVB44G+XGQXxWXbL/Y7pg2sSX4ilJgc+eH7w2Lin
 +SoQ==
X-Gm-Message-State: AOAM531fW7Ew6+RL8yLVB5bFZUlLtX12kw1G3w7gfR8GoBuhgk7HsAP3
 JW1Q/jysTpvGo8qPm6zGdN+Fx5b1IQp3KCwSSL/4OMKVY7c=
X-Google-Smtp-Source: ABdhPJyAapis+ff2anHsbpEuaSXTYj+rKkOr3/lMbzmB9Jg8VkUQ5laLBaZrPlKq2fOQyG7PAEbaPul4XN8lCiT292Q=
X-Received: by 2002:a17:906:9b96:b0:6e8:6e4c:8249 with SMTP id
 dd22-20020a1709069b9600b006e86e4c8249mr6912794ejc.281.1650689777020; Fri, 22
 Apr 2022 21:56:17 -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>
In-Reply-To: <CAMZUoK=GONdGwj34PcqjV5sFJBg+XqiSOHFk4aQoTgy00YFG=Q@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 22 Apr 2022 23:56:02 -0500
Message-ID: <CAGpPWDaSJu-B5VvMxrssag+08m53EaO0TW0P+KusJ8DL98kB7g@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cb323105dd4b29bc"
X-Mailman-Approved-At: Sat, 23 Apr 2022 09:04:59 +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: Sat, 23 Apr 2022 04:56:20 -0000

--000000000000cb323105dd4b29bc
Content-Type: text/plain; charset="UTF-8"

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

On Fri, Apr 22, 2022 at 12:25 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This vault design (https://github.com/jamesob/simple-ctv-vault)
>> is a good benchmark for evaluating covenant proposals because it's (i)
>> simple and (ii) has high utility for many users of Bitcoin. I would
>> love to see it implemented in one or all of these alternatives, but I
>> am almost certain no one will do it in the next few months because the
>> implementations, tooling, and in some cases even complete
>> specifications do not exist.
>>
>
> Quoting from the link above:
> Detecting theft
>
> This unvault step is critical because it allows us to detect unexpected
> behavior. If an attacker had stolen our hot wallet keys, their only choice
> to succeed in the theft is to trigger an unvault.
>
>
> 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.
>
> A key feature of the MES vault design is that the destination address is
> included, and committed to, by the unvaulting step.  However, this can only
> be achieved with a less constrained design for covenants.
>
> I suppose I can see that the damage from a hot key theft could be more
> contained under some circumstances using a CTV vault, but let us not
> overstate the value of the CTV vault.
>
> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>&gt; If an attacker steals the hot key, then they hav=
e the option to simply wait for the user to unvault their funds</div><div><=
br></div>This is definitely true. Its kind of a problem with=C2=A0most vaul=
t proposals. Its one of the primary reasons I designed <a href=3D"https://g=
ithub.com/fresheneesz/bip-efficient-bitcoin-vaults">an alternative proposal=
</a>. The OP_BEFOREBLOCKVERIFY opcode I proposed solves this security hole =
by automatically swapping control of the UTXO over to the intended recipien=
t after a timeout. Alternatively, if OP_BBV weren&#39;t available, OP_POS i=
n conjunction with OP_CD could encode things such that the transaction with=
=C2=A0the hot 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 solution to that problem. I&#39;m not aware of any that do other tha=
n my proposal.=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Fri, Apr 22, 2022 at 12:25 PM Russell O&#39;Co=
nnor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"lt=
r">On Fri, Apr 22, 2022 at 12:29 PM James O&#39;Beirne 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><div class=3D=
"gmail_quote"><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">This vault design (<a href=3D"https://github.com/jamesob/simple-ctv-v=
ault" target=3D"_blank">https://github.com/jamesob/simple-ctv-vault</a>)<br=
><div dir=3D"ltr">is a good benchmark for evaluating covenant proposals bec=
ause it&#39;s (i)<br>simple and (ii) has high utility for many users of Bit=
coin. I would<br>love to see it implemented in one or all of these alternat=
ives, but I<br>am almost certain no one will do it in the next few months b=
ecause the<br>implementations, tooling, and in some cases even complete <br=
></div><div dir=3D"ltr">specifications do not exist.<br></div></div></block=
quote><div><br></div>Quoting from the link above:</div><div class=3D"gmail_=
quote"></div><div class=3D"gmail_quote" style=3D"margin-left:40px"><h3>Dete=
cting theft</h3>
<p>This unvault step is critical because it allows us to detect unexpected =
behavior. If an attacker
had stolen our hot wallet keys, their only choice to succeed in the theft i=
s to trigger an unvault.</p></div><div class=3D"gmail_quote"><p><br></p><p>=
It&#39;s not the attackers *only choice to succeed*.=C2=A0 If an attacker s=
teals 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.=C2=A0 Indeed, this is what we expect would hap=
pen in the dark forest.<br></p><p>A key feature of the MES vault design is =
that the destination address is included, and committed to, by the unvaulti=
ng step.=C2=A0 However, this can only be achieved with a less constrained d=
esign for covenants.</p><p>I suppose I can see that the damage from a hot k=
ey theft could be more contained under some circumstances using a CTV vault=
, but let us not overstate the value of the CTV vault.<br></p><p>And that&#=
39;s not even mentioning the issues already noted by the document regarding=
 fee management, which would likely also benefit from a less constrained de=
sign for covenants.<br></p></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>

--000000000000cb323105dd4b29bc--