From: "Russell O'Connor" <roconnor@blockstream•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
Date: Sat, 23 Apr 2022 10:02:36 -0400 [thread overview]
Message-ID: <CAMZUoKnVTVK=GDhTbsBVa0j82TCvr4YrwjnEm+o6EKueMR7ofQ@mail.gmail.com> (raw)
In-Reply-To: <CAGpPWDaSJu-B5VvMxrssag+08m53EaO0TW0P+KusJ8DL98kB7g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]
On Sat, Apr 23, 2022 at 12:56 AM Billy Tetrud <billy.tetrud@gmail•com>
wrote:
> > 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.
>
As I noted, the original MES vault
https://fc16.ifca.ai/bitcoin/papers/MES16.pdf, commits to the destination
address during unvaulting. Their proposal uses CheckOutputVerify that
checks if a given output has a given amount and a given scriptPubKey. (The
MES vault then goes on to add a PATTERN parameter to OP_COV's scriptPubKey
parameter in order to make a recursive vault, but that is used to deter
cold-key theft, not hot-key theft).
Our paper https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
impelments the MES vault in Elements (alpha) using CAT and
CHECKSIGFROMSTACK. While I wouldn't necessarily call it a covenant
proposal, rather it is an observation that these opcodes happen to be
adequate for the task.
With such a big security caveat, I really don't find CTV vaults a
compelling example of using CTV. Sure, if CTV happens to exist, by all
means do whatever you like. But if anything, the CTV vault scheme instead
illustrates BlueMatt's point that we aren't really finished with covenant
research design yet:
Q: What ways can we build a secured vault that commits to the destination
address?
Q: Are there elegant ways of building secure vaults by using CTV plus
something else. Presumably CAT + CTV would be enough, though maybe some
people are concerned that CAT might enable recursive covenants (if people
aren't willing to have even CAT, I don't see how we will ever really have
programmable money).
[-- Attachment #2: Type: text/html, Size: 3016 bytes --]
next prev parent reply other threads:[~2022-04-23 14:02 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
2022-04-23 14:02 ` Russell O'Connor [this message]
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='CAMZUoKnVTVK=GDhTbsBVa0j82TCvr4YrwjnEm+o6EKueMR7ofQ@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