path: root/12/ae8e925e389fb1f391d1e08771f01e5a946acc

Return-Path: <zachgrw@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 557ADC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Jul 2021 11:18:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 37183400D2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Jul 2021 11:18:24 +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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id eeWkNaFvJUvb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Jul 2021 11:18:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com
 [IPv6:2607:f8b0:4864:20::136])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 0A445400DB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Jul 2021 11:18:22 +0000 (UTC)
Received: by mail-il1-x136.google.com with SMTP id k3so11732785ilu.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Jul 2021 04:18:22 -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;
 bh=b5LYiHbD+LFfq2o7IxTdSxY1w8kq6Mdaszxz7A1Hh38=;
 b=pK80qHZ/dbzNpafugTGfgOY1Rd5fXrLIspUgbxe3L15Ca98UbMPkfMDKBDJXaceeVx
 tu8brmI9g8mEaUyAAUnBGKFvkUPiuigi41jA++jrtLvrSVbO0NQXdVvXzv0QKHR4Q3ep
 LpDFUJe0cYfaE+0pVwlcHPaj4qyt5O8NmNYVgqI2clW+nxWM9Mum+IwOXUgXBGppVgi+
 EqJraVRDC0DqPl4Tic98l5iw+xkHapxHI1ai/3fzIB0RWyuuvO7QgHaphUHSqaygXXTJ
 BWTHJuci8Ov0U2nJQ15YBOeF79YSiJ4DLBi9PZ3d6EjUp9/dUb6+5SonETaWvTbprgc1
 Ffbg==
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;
 bh=b5LYiHbD+LFfq2o7IxTdSxY1w8kq6Mdaszxz7A1Hh38=;
 b=X7rSFNK8D4wv/AvwahvadctbjCoH1jh6KF4y3v4uF1NKHYlRM7NytAWdFhIkuaJ7Vg
 nebrhOyoDYDA/998YXLi5fIQDeO1jKHTVYTpeFfbkiBpoZUgK8KOoyxEOmDg5gL1ZHxH
 Qutcf6t9sNyEG4pJutwbM5s+T5ogt8Ddm2ItRn3bwtHKJ1dV1AzNQyQlcS36BiGmmURk
 K8oQUtFwhSfdYfgDG4q+h5p2bV0x5wVuYaLl+2/8gJa4gX96SverYrTShczzP6/QUC17
 FPvhi8btHSqcQCJKDDiippvMHydIBWUzArYs80xPIZnt4IHFXOmw09AVknlxjwMjh6rB
 8dOg==
X-Gm-Message-State: AOAM532R0XN+2tFWjyGAfOE6AW7yoNIL9uSvE4bOTiMVj45hk82TUqUD
 DT/Dn0dCJ51cae/hrletZg2cpcJPTbPIEk1kZCk=
X-Google-Smtp-Source: ABdhPJwRC5t/eIfuTf08wLFBtBEFyU51SzuipnS2mXRGXivg0niSmu6sUZfUAtZ2yo6dxIXjtjwuX+QM9tbrJCp/B3E=
X-Received: by 2002:a92:7d08:: with SMTP id y8mr16287182ilc.111.1627384702106; 
 Tue, 27 Jul 2021 04:18:22 -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>
 <CAGpPWDb8yzGO-VtCO-x09e-phKHT7ezOms+DzeWc9vS3rN1AAw@mail.gmail.com>
In-Reply-To: <CAGpPWDb8yzGO-VtCO-x09e-phKHT7ezOms+DzeWc9vS3rN1AAw@mail.gmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Tue, 27 Jul 2021 13:18:11 +0200
Message-ID: <CAJ4-pEDWuNfdE4NXkZBsOnuSQ4YOv28YVwGavyiU+FPvpC6y1w@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000001501c605c8190772"
X-Mailman-Approved-At: Tue, 27 Jul 2021 12:25:12 +0000
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 11:18:24 -0000

--0000000000001501c605c8190772
Content-Type: text/plain; charset="UTF-8"

Hi Billy,

On the topic of wallet vaults, are there any plans to implement a way to
limit the maximum amount to be sent from an address?

An example of such limit might be: the maximum amount allowed to send is
max(s, p) where s is a number of satoshi and p a percentage of the total
available (sendable) amount.

A minimum value may be imposed on the percentage to ensure that the address
can be emptied within a reasonable number of transactions. The second
parameter s allows a minimum permitted amount. (This is necessary because
with only the percentage parameter the minimum permitted amount converges
to zero, making it impossible to empty the address).

There may be other ways too. In my view, such kind of restriction would be
extremely effective in thwarting the most damaging type of theft being the
one where all funds are swept in a single transaction.

Zac


On Tue, 27 Jul 2021 at 03:26, Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">Hi Billy,</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">On the topic of wallet vaults, are there any plans to implement a way t=
o limit the maximum amount to be sent from an address?</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">An example of such limit might be: the maxim=
um amount allowed to send is max(s, p) where s is a number of satoshi and p=
 a percentage of the total available (sendable) amount.</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">A minimum value may be imposed on the perce=
ntage to ensure that the address can be emptied within a reasonable number =
of transactions. The second parameter s allows a minimum permitted amount. =
(This is necessary because with only the percentage parameter the minimum p=
ermitted amount converges to zero, making it impossible to empty the addres=
s).=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">There may be o=
ther ways too. In my view, such kind of restriction would be extremely effe=
ctive in thwarting the most damaging type of theft being the one where all =
funds are swept in a single transaction.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Zac</div><div dir=3D"auto"><br></div><div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 27 Jul 2021 =
at 03:26, Billy Tetrud via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-=
left-color:rgb(204,204,204)"><div dir=3D"ltr">Hey James,<div><br></div><div=
>In the examples you mentioned, what I was exploring was a mechanism of att=
ack by which the attacker could steal user A&#39;s key and use that key to =
send a transaction with the maximum possible fee. User B would still receiv=
e 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 w=
ith a miner to give back some of the large fee (theft).=C2=A0</div><div><br=
></div><div>But as for use cases, the proposal mentions <a href=3D"https://=
github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constr=
aindestination.md#motivation" target=3D"_blank">a number of use cases</a>=
=C2=A0and most overlap with the <a href=3D"https://utxos.org/uses/" target=
=3D"_blank">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 op_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 use, for =
example, 1 key to spend funds, but the attacker must steal 2 or more keys t=
o 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 stil=
l recover their funds (better redundancy) and also that generally the 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 ste=
al). 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 w=
ould 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 som=
ewhat akin to a lightning watchtower scenario, where your wallet would watc=
h the chain and alert you about an unexpected transaction, at which point y=
ou&#39;d manually do a revoke (vs a watchtower&#39;s automated response). Y=
ou might be interested in taking a look at <a href=3D"https://github.com/fr=
esheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md" t=
arget=3D"_blank">this wallet vault design</a> that uses OP_CD or even <a hr=
ef=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-vaults" target=
=3D"_blank">my full vision</a> of the wallet vault I want to be able to cre=
ate.</div><div><br></div><div>With a covenant opcode like this, its possibl=
e to create very usable and accessible but highly secure wallets that can a=
llow 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 se=
cure seed storage locations).=C2=A0</div><div><br></div><div>Cheers,</div><=
div>BT</div><div><br></div><div><br></div><div><br></div><div><br></div></d=
iv><br><div class=3D"gmail_quote"><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" target=3D"_blank">macwhyte@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(=
204,204,204)"><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"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:=
solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir=3D"ltr"=
><div><span>See above, but to break down that situation a bit further, thes=
e 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 th=
e output to user/group B</li><li style=3D"padding-bottom:0.6001em">The opco=
de limits user A to send from one address they own to another address they =
own.=C2=A0</li></ol></div></div></div></blockquote><div><span>I&#39;m tryin=
g to think of a good use case for this type of opcode. In these examples, a=
n attacker who compromises the key for user A can&#39;t steal the money bec=
ause it can only be sent to user B. So if the attacker wants to steal the f=
unds, they would need to compromise the keys of both user A and user B.</sp=
an></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?</sp=
an><br></div><div><span><br></span></div><div><span>James</span></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></div>

--0000000000001501c605c8190772--