From: "Russell O'Connor" <roconnor@blockstream•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
Date: Fri, 22 Apr 2022 13:25:12 -0400 [thread overview]
Message-ID: <CAMZUoK=GONdGwj34PcqjV5sFJBg+XqiSOHFk4aQoTgy00YFG=Q@mail.gmail.com> (raw)
In-Reply-To: <CAPfvXfJe6YHViquT8i+Kq2QUjZDZyUq24nKkJd2a6dYKgygxNQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2306 bytes --]
next prev parent reply other threads:[~2022-04-22 17:25 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 ` Russell O'Connor [this message]
2022-04-23 4:56 ` [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) Billy Tetrud
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='CAMZUoK=GONdGwj34PcqjV5sFJBg+XqiSOHFk4aQoTgy00YFG=Q@mail.gmail.com' \
--to=roconnor@blockstream$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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