public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail.com>
To: James MacWhyte <macwhyte@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)
Date: Mon, 26 Jul 2021 17:41:29 -0700	[thread overview]
Message-ID: <CAGpPWDb8yzGO-VtCO-x09e-phKHT7ezOms+DzeWc9vS3rN1AAw@mail.gmail.com> (raw)
In-Reply-To: <CAH+Axy7cPufMUCMQbCz2MUgRqQbgenAozPBFD8kPYrSjwcRG8w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4404 bytes --]

  reply	other threads:[~2021-07-27  0:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21  5:56 [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) Billy Tetrud
2021-07-25  5:38 ` David A. Harding
2021-07-25 19:49   ` Billy Tetrud
2021-07-26  0:05     ` David A. Harding
     [not found]       ` <SN7PR18MB3981DC1CD23B90367045995FD2E89@SN7PR18MB3981.namprd18.prod.outlook.com>
2021-07-26 20:18         ` Billy Tetrud
2021-07-26 21:08     ` James MacWhyte
2021-07-27  0:41       ` Billy Tetrud [this message]
2021-07-27 11:18         ` Zac Greenwood
2021-07-27 17:21           ` Billy Tetrud
2021-07-28  4:57             ` Zac Greenwood
2021-07-28 17:57               ` Billy Tetrud
2021-07-28 22:30                 ` Jeremy
2021-07-30 18:42                   ` Billy Tetrud
2021-11-01  1:19                     ` Billy Tetrud
2021-07-31 20:01                 ` [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood
2021-08-02  4:40                   ` Billy Tetrud
2021-08-10  2:17                   ` ZmnSCPxj
2021-08-13 11:02                     ` Zac Greenwood
2021-08-14  1:50                       ` ZmnSCPxj
2021-08-16 11:17                         ` Zac Greenwood
2021-08-16 11:48                           ` ZmnSCPxj
2021-08-30 14:43                             ` Zac Greenwood
2021-08-31  9:00                               ` ZmnSCPxj
2021-08-31 14:09                                 ` Zac Greenwood
2021-08-31 14:22                                   ` ZmnSCPxj
2021-09-01 15:15                                     ` Zac Greenwood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGpPWDb8yzGO-VtCO-x09e-phKHT7ezOms+DzeWc9vS3rN1AAw@mail.gmail.com \
    --to=billy.tetrud@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=macwhyte@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox