path: root/12/e1e4a91b5c07fb40ba8d25792cff4aa025a34f

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 275BCC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Jul 2021 00:41:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 02FF5607B9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Jul 2021 00:41:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, 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 dHIOIFdJ4kSI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Jul 2021 00:41:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [IPv6:2a00:1450:4864:20::52f])
 by smtp3.osuosl.org (Postfix) with ESMTPS id B42396076C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Jul 2021 00:41:47 +0000 (UTC)
Received: by mail-ed1-x52f.google.com with SMTP id r16so12996831edt.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Jul 2021 17:41:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=snRLlljWokZsTAKm3L2U4bhBfcCSpp2qRBOVgHEdzOU=;
 b=XJNYNpTBXQvTxQSrZvUV/eA0hY7fKUXw6ypu6N40yzQFknbmIIb6qWIrSOTaZTHqMI
 Dd+4VXJo8RuXYuCz/C6SaW8yxcToP8Iup6BnGgZKfqfuasLzmTrRyPa5FkwHtqCqBnoe
 hqLBNzwqK7ltsnjaGsEqdM1/jER5RyVOxCpj7F+adTmqVJ1x3xefx7hgmZ5L7OhpsqR4
 esehaitYIFy3RulKoIwW00eywXiprlprQ1QTRNgPxhQmkbAcEbV16hDUq6d7QHMuYG3b
 oXWyn+J2XI4q0HkSZZQqUpVRTUDVwSfIEuUxNuGZnK04JHdBpKIWDskgy9mTBSnxZABE
 59AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=snRLlljWokZsTAKm3L2U4bhBfcCSpp2qRBOVgHEdzOU=;
 b=aE6EHvkFaV+rd1/cGPMeq8vXoB8eas4ibZEyz+gzYyJEEiTd3m7wZ2b+bZh/a615Ii
 57DaoGzhY28F5K5+t7dS5RuQHUUGLIM/vzeZInXkvfktDG+tYDPbDcRFDc0xq9gf3Opp
 s/KVP2eijo+fT+TnrrPBK4aNoCEIod45Lj6EBJw1aZoJ3yr6AJTJivy23pf3UTgTJ6yQ
 NuJB2rNd/fxEEGZIrEsjdHAx3FCXdRpWQx9J6ZPkV/wWxlRH+Prmub4b3dogDXldyKqz
 sjdPzDqhknevYXtvf8qw+QVI9NYaKFYN8P8Xhw+LV7HwNjoqlXtudZutG0EsTzOW35X9
 N7pA==
X-Gm-Message-State: AOAM533JLgcReY4Pn1Lgntbj71hwbost6D9RuIAfykjGuGuGab9w2rdY
 aJPtu9b/FIzfImlCdRkt++MjNk8x1+DzpBSxw2s=
X-Google-Smtp-Source: ABdhPJxxY9Hju5K4ATOF5ZasoH7mK8LJJ4sPpiJ6nx165Fltj6KgNfMN1eF3KF0PXWhg+1NPg7NioDlQvmhCYMJ7ppE=
X-Received: by 2002:aa7:c810:: with SMTP id a16mr15878046edt.338.1627346505729; 
 Mon, 26 Jul 2021 17:41:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
 <20210725053803.fnmd6etv3f7x3u3p@ganymede>
 <CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com>
 <CAH+Axy7cPufMUCMQbCz2MUgRqQbgenAozPBFD8kPYrSjwcRG8w@mail.gmail.com>
In-Reply-To: <CAH+Axy7cPufMUCMQbCz2MUgRqQbgenAozPBFD8kPYrSjwcRG8w@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 26 Jul 2021 17:41:29 -0700
Message-ID: <CAGpPWDb8yzGO-VtCO-x09e-phKHT7ezOms+DzeWc9vS3rN1AAw@mail.gmail.com>
To: James MacWhyte <macwhyte@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000066893e05c81022f7"
X-Mailman-Approved-At: Tue, 27 Jul 2021 01:25:59 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION
 (an alternative to OP_CTV)
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: Tue, 27 Jul 2021 00:41:49 -0000

--00000000000066893e05c81022f7
Content-Type: text/plain; charset="UTF-8"

Hey James,

In the examples you mentioned, what I was exploring was a mechanism of
attack by which the attacker could steal user A's key and use that key to
send a transaction with the maximum possible fee. User B would still
receive some funds (probably), but if the fee could be large, the attacker
would either do a lot of damage to user B (griefing) or could make an
agreement with a miner to give back some of the large fee (theft).

But as for use cases, the proposal mentions a number of use cases
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#motivation>
and
most overlap with the use cases of op_ctv <https://utxos.org/uses/> (Jeremy
Rubin's website for op_ctv has a lot of good details, most of which are
also relevant to op_cd). The use case I'm most interested in is wallet
vaults. This opcode can be used to create a wallet vault where the user
only needs to use, for example, 1 key to spend funds, but the attacker must
steal 2 or more keys to spend funds. The benefits of a 2 key wallet vault
like this vs a normal 2-of-2 multisig wallet are that not only does an
attacker have to steal both keys (same level of security), but also the
user can lose one key and still recover their funds (better redundancy) and
also that generally the user doesn't need to access their second key - so
that can remain in a much more secure location (which would also probably
make that key harder to steal). The only time the second key only comes
into play if one key is stolen and the attacker attempts to send a
transaction. At that point, the user would go find and use his second key
(along with the first) to send a revoke transaction to prevent the attacker
from stealing their funds. This is somewhat akin to a lightning watchtower
scenario, where your wallet would watch the chain and alert you about an
unexpected transaction, at which point you'd manually do a revoke (vs a
watchtower's automated response). You might be interested in taking a look
at this wallet vault design
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md>
that uses OP_CD or even my full vision
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> of the wallet
vault I want to be able to create.

With a covenant opcode like this, its possible to create very usable and
accessible but highly secure wallets that can allow normal people to hold
self custody of their keys without fear of loss or theft and without the
hassle of a lot of safe deposit boxes (or other secure seed storage
locations).

Cheers,
BT





On Mon, Jul 26, 2021 at 2:08 PM James MacWhyte <macwhyte@gmail.com> wrote:

> Hi Billy!
>
> See above, but to break down that situation a bit further, these are the
>> two situations I can think of:
>>
>>    1. The opcode limits user/group A to send the output to user/group B
>>    2. The opcode limits user A to send from one address they own to
>>    another address they own.
>>
>> I'm trying to think of a good use case for this type of opcode. In these
> examples, an attacker who compromises the key for user A can't steal the
> money because it can only be sent to user B. So if the attacker wants to
> steal the funds, they would need to compromise the keys of both user A and
> user B.
>
> But how is that any better than a 2-of-2 multisig? Isn't the end result
> exactly the same?
>
> James
>

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

<div dir=3D"ltr">Hey James,<div><br></div><div>In the examples you mentione=
d, what I was exploring was a mechanism of attack by which the attacker cou=
ld steal user A&#39;s key and use that key to send a transaction with the m=
aximum possible fee. User B would still receive some funds (probably), but =
if the fee could be large, the attacker would either do a lot of damage to =
user B (griefing) or could make an agreement with a miner to give back some=
 of the large fee (theft).=C2=A0</div><div><br></div><div>But as for use ca=
ses, the proposal mentions <a href=3D"https://github.com/fresheneesz/bip-ef=
ficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#motivation"=
>a number of use cases</a>=C2=A0and most overlap with the <a href=3D"https:=
//utxos.org/uses/">use cases of op_ctv</a>=C2=A0(Jeremy Rubin&#39;s website=
 for op_ctv has a lot of good details, most of which are also relevant to o=
p_cd). The use case I&#39;m most interested=C2=A0in is wallet vaults. This =
opcode can be used to create a wallet vault where the user only needs to us=
e, for example, 1 key to spend funds, but the attacker must steal 2 or more=
 keys to spend funds. The benefits of a 2 key wallet vault like this vs a n=
ormal 2-of-2 multisig wallet are that not only does an attacker have to ste=
al both keys (same level of security), but also the user can lose one key a=
nd still recover their funds (better redundancy) and also that generally th=
e user doesn&#39;t need to access their second key - so that can remain in =
a much more secure location (which would also probably make that key harder=
 to steal). The only time the second key only comes into play if one key is=
 stolen and the attacker attempts to send a transaction. At that point, the=
 user would go find and use his second key (along with the first) to send a=
 revoke transaction to prevent the attacker from stealing their funds. This=
 is somewhat akin to a lightning watchtower scenario, where your wallet wou=
ld watch the chain and alert you about an unexpected transaction, at which =
point you&#39;d manually do a revoke (vs a watchtower&#39;s automated respo=
nse). You might be interested in taking a look at <a href=3D"https://github=
.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault=
1.md">this wallet vault design</a> that uses OP_CD or even <a href=3D"https=
://github.com/fresheneesz/bip-efficient-bitcoin-vaults">my full vision</a> =
of the wallet vault I want to be able to create.</div><div><br></div><div>W=
ith a covenant opcode like this, its possible to create very usable and acc=
essible but highly secure wallets that can allow normal people to hold self=
 custody of their keys without fear of loss or theft and without the hassle=
 of a lot of safe deposit boxes (or other secure seed storage locations).=
=C2=A0</div><div><br></div><div>Cheers,</div><div>BT</div><div><br></div><d=
iv><br></div><div><br></div><div><br></div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 26, 2021 at 2:08 PM =
James MacWhyte &lt;<a href=3D"mailto:macwhyte@gmail.com">macwhyte@gmail.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">=
<div dir=3D"ltr"><div dir=3D"ltr">Hi Billy!</div><div dir=3D"ltr"><br></div=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div><span>See above, but to break down that situation =
a bit further, these are the two situations I can think of:</span><br></div=
><div><div><ol><li style=3D"padding-bottom:0.6001em">The opcode limits user=
/group A to send the output to user/group B</li><li style=3D"padding-bottom=
:0.6001em">The opcode limits user A to send from one address they own to an=
other address they own.=C2=A0</li></ol></div></div></div></blockquote><div>=
<span>I&#39;m trying to think of a good use case for this type of opcode. I=
n these examples, an attacker who compromises the key for user A can&#39;t =
steal the money because it can only be sent to user B. So if the attacker w=
ants to steal the funds, they would need to compromise the keys of both use=
r A and user B.</span></div><div><span><br></span></div><div><span>But how =
is that any better than a 2-of-2 multisig? Isn&#39;t the end result exactly=
=C2=A0the same?</span><br></div><div><span><br></span></div><div><span>Jame=
s</span></div></div></div>
</blockquote></div>

--00000000000066893e05c81022f7--