Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C3574C002D for ; Sat, 23 Apr 2022 04:56:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 9B2AD60F60 for ; Sat, 23 Apr 2022 04:56:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP3H--BMHqrl for ; Sat, 23 Apr 2022 04:56:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by smtp3.osuosl.org (Postfix) with ESMTPS id 4186060F4C for ; Sat, 23 Apr 2022 04:56:19 +0000 (UTC) Received: by mail-ej1-x636.google.com with SMTP id ks6so19974583ejb.1 for ; Fri, 22 Apr 2022 21:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wxHOCF3kvw5+/nTzUHw27154SsiVBxyerbY2ZK7xq+o=; b=FH1R5/bmRa5M3PfeJOc2cWsdJX3kQ9ueXvZRh3Qqo+Mdw/5LnOkCWHlwhQaL1tBFGj DLM2lXHOYyGCGKl0VeQRRWWMLPzDXEVP7iDxlzUGOVwK4kjR2gjqkic8almvbZVNtKuc efRjsiKXK/Hq6u/LYlyBA/E6YwWHtMHF9tluAo0JpHTNadHa/khZntTKfLt5UYEhB73e Z/HPBHRnNgA1xt6FnRsCRjVHtYC8ioX00ozchNw+83TPSulxylCtbriBwbVdsVThyx4K b3KDQwMS8RveTdQlYOBEwaPrMlK94RrgEteRYJyUs1P+SLpHZ7uK34VsS/I1u0XsHcPC F4kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wxHOCF3kvw5+/nTzUHw27154SsiVBxyerbY2ZK7xq+o=; b=x9XX6DhLg+0g7vtG5FGq8gbRMdp/5G/nNXVNc3IE56oqO2Jz36MhbOmu++PGN4wsrI k37SZN/YwpnUS1eYcUq5WJWXXbSSmfDulpQSdCC7pTPGj3WdyIWzlJ4GW9whZOWF4a60 JrWYAMRuI2PSurHn/OQqXZFqI8yFXktvKYo3vS3vaMn0Yc2YLeD5QO0GClboPhj1HMOP qAUPOXjBcgYvgIMLm8LssjeSDAUyUskkrcNeTtgLS2LY2/8saUUKxswDFKbh43EpgkW1 /LbqMZYN1crpPQHsB34023jlvCsKcVB44G+XGQXxWXbL/Y7pg2sSX4ilJgc+eH7w2Lin +SoQ== X-Gm-Message-State: AOAM531fW7Ew6+RL8yLVB5bFZUlLtX12kw1G3w7gfR8GoBuhgk7HsAP3 JW1Q/jysTpvGo8qPm6zGdN+Fx5b1IQp3KCwSSL/4OMKVY7c= X-Google-Smtp-Source: ABdhPJyAapis+ff2anHsbpEuaSXTYj+rKkOr3/lMbzmB9Jg8VkUQ5laLBaZrPlKq2fOQyG7PAEbaPul4XN8lCiT292Q= X-Received: by 2002:a17:906:9b96:b0:6e8:6e4c:8249 with SMTP id dd22-20020a1709069b9600b006e86e4c8249mr6912794ejc.281.1650689777020; Fri, 22 Apr 2022 21:56:17 -0700 (PDT) MIME-Version: 1.0 References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org> In-Reply-To: From: Billy Tetrud Date: Fri, 22 Apr 2022 23:56:02 -0500 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000cb323105dd4b29bc" X-Mailman-Approved-At: Sat, 23 Apr 2022 09:04:59 +0000 Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2022 04:56:20 -0000 --000000000000cb323105dd4b29bc Content-Type: text/plain; charset="UTF-8" > 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 . 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 > --000000000000cb323105dd4b29bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> If an attacker steals the hot key, then they hav= e the option to simply wait for the user to unvault their funds
<= br>
This is definitely true. Its kind of a problem with=C2=A0most vaul= t proposals. Its one of the primary reasons I designed an alternative proposal= . The OP_BEFOREBLOCKVERIFY opcode I proposed solves this security hole = by automatically swapping control of the UTXO over to the intended recipien= t after a timeout. Alternatively, if OP_BBV weren't available, OP_POS i= n conjunction with OP_CD could encode things such that the transaction with= =C2=A0the hot key could only spend to the intended recipient.=C2=A0
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 tha= n my proposal.=C2=A0

On Fri, Apr 22, 2022 at 12:25 PM Russell O'Co= nnor 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 bec= ause it's (i)
simple and (ii) has high utility for many users of Bit= coin. I would
love to see it implemented in one or all of these alternat= ives, but I
am almost certain no one will do it in the next few months b= ecause the
implementations, tooling, and in some cases even complete
specifications do not exist.

Quoting from the link above:

Dete= cting 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 i= s to trigger an unvault.


= It's not the attackers *only choice to succeed*.=C2=A0 If an attacker s= teals 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.=C2=A0 Indeed, this is what we expect would hap= pen in the dark forest.

A key feature of the MES vault design is = that the destination address is included, and committed to, by the unvaulti= ng step.=C2=A0 However, this can only be achieved with a less constrained d= esign for covenants.

I suppose I can see that the damage from a hot k= ey 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&#= 39;s not even mentioning the issues already noted by the document regarding= fee management, which would likely also benefit from a less constrained de= sign for covenants.

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000cb323105dd4b29bc--