public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
Date: Fri, 22 Apr 2022 23:56:02 -0500	[thread overview]
Message-ID: <CAGpPWDaSJu-B5VvMxrssag+08m53EaO0TW0P+KusJ8DL98kB7g@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoK=GONdGwj34PcqjV5sFJBg+XqiSOHFk4aQoTgy00YFG=Q@mail.gmail.com>

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

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

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

  reply	other threads:[~2022-04-23  4:56 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21  1:04 [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV David A. Harding
2022-04-21  2:05 ` Luke Dashjr
2022-04-21  3:10   ` alicexbt
2022-04-21  5:56     ` Luke Dashjr
2022-04-21  6:20       ` Jeremy Rubin
2022-04-21  6:37         ` Luke Dashjr
2022-04-21 13:10           ` Jeremy Rubin
2022-04-24 15:22     ` Peter Todd
2022-04-21 14:58 ` Matt Corallo
2022-04-21 18:06   ` David A. Harding
2022-04-21 18:39     ` Matt Corallo
2022-04-21 22:28       ` David A. Harding
2022-04-21 23:02         ` Matt Corallo
2022-04-22  1:20           ` David A. Harding
2022-04-22 18:40             ` Matt Corallo
2022-04-22 18:49               ` Corey Haddad
2022-04-22 16:48         ` James O'Beirne
2022-04-22 17:06           ` James O'Beirne
2022-04-22 16:28       ` James O'Beirne
2022-04-22 17:25         ` [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) Russell O'Connor
2022-04-23  4:56           ` Billy Tetrud [this message]
2022-04-23 14:02             ` Russell O'Connor
2022-04-23 18:24           ` Matt Corallo
2022-04-23 19:30             ` Russell O'Connor
2022-04-24 23:03               ` Billy Tetrud
2022-04-25 17:27                 ` Nadav Ivgi
2022-04-25 22:27                 ` Russell O'Connor
2022-04-27  1:52                   ` Billy Tetrud
2022-04-28 23:14                     ` Nadav Ivgi
2022-04-28 23:51                       ` Billy Tetrud
2022-04-22 18:35         ` [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV Matt Corallo
2022-04-21 19:08 ` Jeremy Rubin
2022-04-22  0:28 ` Anthony Towns
2022-04-22  1:44   ` David A. Harding
2022-04-22 19:57 ` Antoine Riard
2022-04-25  5:12 ` ZmnSCPxj
2022-04-25 16:03 [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks) Buck O Perley
2022-04-27  2:09 ` Billy Tetrud

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=CAGpPWDaSJu-B5VvMxrssag+08m53EaO0TW0P+KusJ8DL98kB7g@mail.gmail.com \
    --to=billy.tetrud@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=roconnor@blockstream.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