public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo•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: Sat, 23 Apr 2022 11:24:01 -0700	[thread overview]
Message-ID: <48a4546c-85b3-e9ff-83b5-60ba4eae2c76@mattcorallo.com> (raw)
In-Reply-To: <CAMZUoK=GONdGwj34PcqjV5sFJBg+XqiSOHFk4aQoTgy00YFG=Q@mail.gmail.com>

Still trying to make sure I understand this concern, let me know if I get this all wrong.

On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
> 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.

Right, a key security assumption of the CTV-based vaults would be that you MUST NOT EVER withdraw 
more in one go than your hot wallet risk tolerance, but given that your attack isn't any worse than 
simply stealing the hot wallet key immediately after a withdraw.

It does have the drawback that if you ever get a hot wallet key stole you have to rotate all of your 
CTV outputs and your CTV outputs must never be any larger than your hot wallet risk tolerance 
amount, both of which are somewhat frustrating limitations, but not security limitations, only 
practical ones.

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

Of course I've always been in favor of a less constrained covenants design from day one for ten 
reasons, but that's a whole other rabbit hole :)


  parent reply	other threads:[~2022-04-23 18:24 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
2022-04-23 18:24           ` Matt Corallo [this message]
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=48a4546c-85b3-e9ff-83b5-60ba4eae2c76@mattcorallo.com \
    --to=lf-lists@mattcorallo$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=roconnor@blockstream$(echo .)com \
    /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