Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

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