diff options
| author | Billy Tetrud <billy.tetrud@gmail.com> | 2022-04-26 21:09:03 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-27 02:09:23 +0000 |
| commit | d96a3886a6092d1a8bd37b4cffae9802276c9969 (patch) | |
| tree | b6c8acf3a9e7f82e2084dadfde8580762a364a13 | |
| parent | b6db2f36593b6146049384c3da94f849c452c4f4 (diff) | |
| download | pi-bitcoindev-d96a3886a6092d1a8bd37b4cffae9802276c9969.tar.gz pi-bitcoindev-d96a3886a6092d1a8bd37b4cffae9802276c9969.zip | |
Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks)
| -rw-r--r-- | 4f/3d2733c7b89f9f6cfa8b853129d14dfcd49dbc | 804 |
1 files changed, 804 insertions, 0 deletions
diff --git a/4f/3d2733c7b89f9f6cfa8b853129d14dfcd49dbc b/4f/3d2733c7b89f9f6cfa8b853129d14dfcd49dbc new file mode 100644 index 000000000..ff3d0a5b9 --- /dev/null +++ b/4f/3d2733c7b89f9f6cfa8b853129d14dfcd49dbc @@ -0,0 +1,804 @@ +Return-Path: <fresheneesz@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 77A7CC002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Apr 2022 02:09:23 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 7049A417E1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Apr 2022 02:09:23 +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: smtp4.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id kgujbyid8SEY + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Apr 2022 02:09:21 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com + [IPv6:2a00:1450:4864:20::630]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 156B1417DF + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 27 Apr 2022 02:09:20 +0000 (UTC) +Received: by mail-ej1-x630.google.com with SMTP id kq17so602648ejb.4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 26 Apr 2022 19:09:20 -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=LxI4XJTsQd2GadHF7i3HmXm75NP2vBF0tt+UA9mEXDE=; + b=dGDYTzg0lDNI/DnrhgT1cAVCwh4WU/kw+31nwpj55cG4PfMZFx2V9ajZ+HujqOORG3 + BlKwJmTGRCw6RrHnfzS5Cf6yrWhCjwGae0bnf8s95QsXCVWwtlfEdqpb7r6IstdrPi1x + kIMRxWsZwSKz54eOACN9A+MEpvQChSZ56F1yycqYE2wiPaFkewMM+yIr9vkQm2ECA6y+ + 7RDxVWSX6RQysXpf6DSaPVz/0iWwkBllRVpxoLs7Rwk4bU8Oxe9iliVEDkhWTeVf7LYW + 37TiWtZyiWgg6yLw9TKTvfW3xqrq4MwPUGHjXMDzm0AB3xkpHzZ9Uo5RBv2xGn5xel17 + 1YhA== +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=LxI4XJTsQd2GadHF7i3HmXm75NP2vBF0tt+UA9mEXDE=; + b=YVxwONQX7ukN9HCqftyj0ifmh35fjKQMWy6glsj5QgQcrPfGaqYPafXhgZOZrDRzO5 + whOEJHITxcJIdw8NkVR9YyyUz2kBWjsEaL/Ks5910bnPZPEvhaI0FgnzJxECR3uPralT + gOnbC7oMwVxbUSg8QSUukoi+7AeBg5hoiHQsuGR5MBPbr0PiFLjfXshfPi01AUGyHYKN + 8UdvkArSWoLseyGhc4134cneEdTu8st8KNeHICH2IRBALxhC6fJLlZ0i0wlBuvNZepeF + pg+dSailQIcDPCKI6akuFrFIr0S6vwGy5AkQAyVyRYg6djwayuJt9Fi4JIQ+iwL0VH3z + 62qQ== +X-Gm-Message-State: AOAM532eCHv9bpbjmtInvmgUk3C5IWeZG67MoQTWjhI69N2Oj0X3YA0l + 1C5wSpQdHh2XaiZ8dk0PH8qLfG7Rsu1mpI85La7RxDm1qjM= +X-Google-Smtp-Source: ABdhPJyUJQ+RGJV0PC6VJOhb6HS6poe8KKJK6+SwQN6ljoi9SNFH2bbw0VKg1QBLrwlfkDh1TkAFHXkTB4mK8OZycOk= +X-Received: by 2002:a17:907:3daa:b0:6e8:969d:564d with SMTP id + he42-20020a1709073daa00b006e8969d564dmr23601147ejc.735.1651025358856; Tue, 26 + Apr 2022 19:09:18 -0700 (PDT) +MIME-Version: 1.0 +References: <cn2quZuZeFKn3KjA0y3LaSTi9DIaFywY7dYdAfDnJqL7StqG6ljplYmNi-7sQ11J-_PR--FLAFMrqViqIqiBU9BWf8t5kO2zDRknwPyNfY0=@protonmail.com> +In-Reply-To: <cn2quZuZeFKn3KjA0y3LaSTi9DIaFywY7dYdAfDnJqL7StqG6ljplYmNi-7sQ11J-_PR--FLAFMrqViqIqiBU9BWf8t5kO2zDRknwPyNfY0=@protonmail.com> +From: Billy Tetrud <billy.tetrud@gmail.com> +Date: Tue, 26 Apr 2022 21:09:03 -0500 +Message-ID: <CAGpPWDbMB9aT4rqAG-4RnWRZuLpeesZ7JHydtYgT5ohNNy_VHw@mail.gmail.com> +To: Buck O Perley <buck.perley@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000007a69405dd994c71" +X-Mailman-Approved-At: Wed, 27 Apr 2022 08:09:15 +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 27 Apr 2022 02:09:23 -0000 + +--00000000000007a69405dd994c71 +Content-Type: text/plain; charset="UTF-8" + +> the hot wallet can only spend a certain amount from the hot wallet spend +and the rest would .. be sent back + +That would definitely be the way to do it. The ability to steal from the +hot wallet in my opinion shouldn't really be a "concern" about CTV, but +rather an understood tradeoff of a CTV wallet vault. In fact, its hardly +even a trade off - a CTV vault can be created that is usable exactly as a +normal multisig wallet if the user wants to use it that way. The unvaulting +would simply add an additional (and optional) usability improvement over +normal multisig. The security considerations around choosing the +appropriate maximum amount to unvault at a time (with one key) is just +something that someone would need to decide based on basically their +comfort level. It sounds like you said something very similar in your point +2. + +Would I like to have a wallet vault that doesn't have this security +consideration? Sure. But that isn't to say a wallet vault with that hitch +isn't a very useful advance to self-custody setups. + +> You also get the nice benefit of learning about compromised keys without +having to risk all funds associated with that key. + +This is an interesting tack-on attribute. A built in honey pot. If you only +allow 1% of your savings to be taken out at a time (with one key), is 1% of +your savings worth knowing that your wallet has been partially compromised? +Maybe it would be. + + + +On Mon, Apr 25, 2022 at 11:51 AM Buck O Perley via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Just a couple of comments re-CTV vault security concerns. +> +> +> 1. One way to assuage the concern of the hot wallet vulnerability +> is pre-program the spends such that the hot wallet can only +> spend a certain amount from the hot wallet spend and the rest would +> kind of be "recursive" in that it would be sent back to a +> new instantiation of the CTV vault. I believe kanzure's vaults +> does this w/ the non-covenant version using pre-signed transactions +> (https://github.com/kanzure/python-vaults). While this doesn't +> prevent the theft it caps off the total risk. I would argue that +> this is strictly better than a multisig because you can also use +> multisig as you normally would if you want but you have the option +> if you think your hot key is secure to use that spending path. +> You also get the nice benefit of learning about compromised +> keys without having to risk all funds associated with that key. +> +> +> 2. As to how to improve UX for CTV with other proposals, I think +> you get a lot of benefits when using with taproot because you can +> use CTV in tapleaves to secure specific spend conditions, but can +> always fall back to other off-ramps (e.g. a musig key path spend or +> other script path conditions). Of course you can do this without +> taproot but taproot makes this more space efficient. This idea has +> been used to some effect in some recent exploration of how CTV can +> help improve UX around DLCs. You could even do this to help with +> the problems of not sending the right amount such that you have a +> really really cold key or set of keys for example such that if you +> have UTXOs that have values that can't be spent with the given CTV +> commitment, then you just use that other branch. +> +> - Buck +> +> ------- Original Message ------- +> +> > Date: Sun, 24 Apr 2022 18:03:52 -0500 +> > 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) +> > Message-ID: +> > CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1A@mail.gmail.com +> > +> +> > Content-Type: text/plain; charset="utf-8" +> > +> +> > @Matt +> > +> +> > > both of which are somewhat frustrating limitations, but not security +> > +> +> > limitations, only practical ones. +> > +> +> > So I think the first limitation you mentioned (that if your hot wallet's +> > key gets stolen you need) can be legitimately considered a security +> > limitation. Not because you need to rotate your keys, but because you +> might +> > not know your hot wallet key has been stolen. If you unvault an output to +> > your hot wallet, the thief could be lying in wait, ready to steal those +> > funds upon them landing. At that point, you would then know your hot +> wallet +> > key was compromised and could rotate your vault keys in order to prevent +> > further theft. However, the fact that there is a clear theft +> vulnerability +> > is something I would say should be considered a "security limitation". +> > +> +> > As you mentioned, this is of course also a security limitation of a hot +> > wallet, so this setup definitely has a lot of advantages over a simple +> hot +> > wallet. However, if you compare it against a multisig wallet (eg 2 of 3), +> > you can see that while theft of a single key would never result in any +> > theft in that setup, it could in a CTV vault. The other trade offs there +> > are ones of practicality and convenience. +> > +> +> > This isn't to say a CTV vault wouldn't be useful. Just that it has +> > significant trade offs. +> > +> +> > @Russel +> > +> +> > > the original MES vault .. commits to the destination address during +> > +> +> > unvaulting +> > +> +> > I see. Looking at the MES16 paper, OP_COV isn't described clearly enough +> > for me to understand that it does that. However, I can imagine how it +> > might do that. +> > +> +> > One possibility is that the intended destination is predetermined and +> > hardcoded. This wouldn't be very useful, and also wouldn't be different +> > than how CTV could do it, so I assume that isn't what you envisioned this +> > doing. +> > +> +> > I can imagine instead that the definition of the pattern could be +> specified +> > as a number indicating the number of stack items in the pattern, followed +> > by that number of stack items. If that's how it is done, I can see the +> user +> > inputting an intended destination script (corresponding to the intended +> > destination address) which would then be somehow rotated in to the right +> > spot within the pattern, allowing the pattern to specify the coins +> > eventually reaching an address with that script. However, this could be +> > quite cumbersome, and would require fully specifying the scripts along +> the +> > covenant pathways leading to a fair amount of information duplication +> > (since scripts must be specified both in the covenant and in spending the +> > subsequent output). Both of these things would seem to make OP_COV in +> > practice quite an expensive opcode to spend with. It also means that, +> since +> > the transactor must fully specify the script, its not possible to take +> > advantage of taproot's script hiding capabilities (were it to send to a +> > taproot address). +> > +> +> > However, my assumptions might be incorrect. If you think OP_COV would be +> a +> > useful opcode, I would encourage you to write up a complete +> specification. +> > +> +> > > What ways can we build a secured vault that commits to the destination +> > +> +> > address? +> > +> +> > Some kind of passed-through state allows doing this. With OP_COV (if my +> > assumptions above are correct), the intended destination can be passed +> > through the output script pattern(s). With my own proposed +> > op_pushoutputstack +> > +> https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md +> , +> > +> +> > state is passed as an attachment on the output more directly. Curious +> what +> > you think about that proposal. +> > +> +> > > Are there elegant ways of building secure vaults by using CTV plus +> > +> +> > something else. +> > +> +> > Since CTV predefines all the transactions that can happen under its +> > control, passed state like this can't help because any dynamic state +> would +> > change the template and render the CTV transaction invalid. I don't see +> any +> > way of solving this problem for CTV. +> > +> +> > I'm curious how you think op_cat could enable this with CTV (other than +> the +> > cat+schnorr tricks that don't require CTV at all). +> > +> +> > +> +> > +> +> > On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev < +> > bitcoin-dev@lists.linuxfoundation.org> wrote: +> > +> +> > > Okay, Matt explained to me the intended application of CTV vaults off +> > > list, so I have a better understanding now. +> > > +> +> > > The CTV vault scheme is designed as an improvement over the traditional +> > > management of hot-wallets and cold-wallets. The CTV vault is logically +> on +> > > the "cold-side" and lets funds be sent from the "cold" side to one's +> own +> > > the hot wallet after the unvaulting delay. In this case, the hot wallet +> > > funds are always at risk, so it isn't unexpected that those funds +> could be +> > > stolen. After all, that is how hot wallets are today. The advantage is +> > > that funds can be moved from the "cold" side without needing to dig +> out the +> > > cold keys. +> > > +> +> > > The MES vault scheme applies to a different scenario. In the MES case +> it +> > > is the hot funds are inside the vault, and it is the hot key that +> unvaults +> > > the funds and sends them to customer's addresses after a delay. If the +> > > hot-key is used in any unauthorised way, then funds can be sent to the +> > > address of the cold key (the MES vault actually does something fancy in +> > > case of recovery, but it could be adapted to simply send funds to a +> cold +> > > wallet). +> > > +> +> > > The MES vault lie somewhere between "better" and "different" when +> compared +> > > to the CTV vault. If one is unwilling to use the MES vault on the hot +> side +> > > and have every withdrawl vetted, then, while you could use the MES +> design +> > > on the cold side like the CTV vault, it wouldn't really offer you any +> > > advantages over a CTV vault. However, if you are interested in managing +> > > all your payments through a vault (as I've been imagining) then the CTV +> > > vault comes across as ineffective when compared to an MES style vault. +> > > +> +> > > On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo lf-lists@mattcorallo.com +> > > wrote: +> > > +> +> > > > 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 :) +> > > +> +> > > _______________________________________________ +> > > bitcoin-dev mailing list +> > > bitcoin-dev@lists.linuxfoundation.org +> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--00000000000007a69405dd994c71 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">>=C2=A0 + +the hot wallet can only spend a certain amount from the hot wallet spend an= +d the rest would .. be sent back<div><br></div><div>That would definitely b= +e the way to do it. The ability to steal from the hot wallet in my opinion = +shouldn't really be a "concern" about CTV, but rather an unde= +rstood tradeoff of a CTV wallet vault. In fact, its hardly even a trade off= + - a CTV vault can be created that is usable exactly as a normal multisig w= +allet if the user wants to use it that way. The unvaulting would simply add= + an additional (and optional) usability improvement over normal multisig. T= +he security considerations around choosing the appropriate maximum amount t= +o unvault at a time (with one key) is just something that someone would nee= +d to decide based on basically their comfort level. It sounds like you said= + something very similar in your point 2.</div><div><br></div><div>Would I l= +ike to have a wallet vault that doesn't have this security consideratio= +n? Sure. But that isn't to say a wallet vault with that hitch isn't= + a very useful advance to self-custody setups.</div><div><br></div><div>>= +; You also get the nice benefit of learning about compromised keys without = +having to risk all funds associated with that key.</div><div><br></div><div= +>This is an interesting tack-on attribute. A built in honey pot. If you onl= +y allow 1% of your savings to be taken out at a time (with one key), is=C2= +=A01% of your savings worth knowing that your wallet has been partially com= +promised? Maybe it would be.<br><div><br></div><div><br></div></div></div><= +br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon,= + Apr 25, 2022 at 11:51 AM Buck O Perley via bitcoin-dev <<a href=3D"mail= +to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation= +.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar= +gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= +ex">Just a couple of comments re-CTV vault security concerns.<br> +<br> +<br> +1. One way to assuage the concern of the hot wallet vulnerability<br> +is pre-program the spends such that the hot wallet can only<br> +spend a certain amount from the hot wallet spend and the rest would<br> +kind of be "recursive" in that it would be sent back to a<br> +new instantiation of the CTV vault. I believe kanzure's vaults<br> +does this w/ the non-covenant version using pre-signed transactions<br> +(<a href=3D"https://github.com/kanzure/python-vaults" rel=3D"noreferrer" ta= +rget=3D"_blank">https://github.com/kanzure/python-vaults</a>). While this d= +oesn't<br> +prevent the theft it caps off the total risk. I would argue that<br> +this is strictly better than a multisig because you can also use<br> +multisig as you normally would if you want but you have the option<br> +if you think your hot key is secure to use that spending path.<br> +You also get the nice benefit of learning about compromised<br> +keys without having to risk all funds associated with that key.<br> +<br> +<br> +2. As to how to improve UX for CTV with other proposals, I think<br> +you get a lot of benefits when using with taproot because you can<br> +use CTV in tapleaves to secure specific spend conditions, but can<br> +always fall back to other off-ramps (e.g. a musig key path spend or<br> +other script path conditions). Of course you can do this without<br> +taproot but taproot makes this more space efficient. This idea has<br> +been used to some effect in some recent exploration of how CTV can<br> +help improve UX around DLCs. You could even do this to help with<br> +the problems of not sending the right amount such that you have a<br> +really really cold key or set of keys for example such that if you<br> +have UTXOs that have values that can't be spent with the given CTV<br> +commitment, then you just use that other branch.<br> +<br> +- Buck<br> +<br> +------- Original Message -------<br> +<br> +> Date: Sun, 24 Apr 2022 18:03:52 -0500<br> +> From: Billy Tetrud <a href=3D"mailto:billy.tetrud@gmail.com" target=3D= +"_blank">billy.tetrud@gmail.com</a><br> +> <br> +<br> +> To: "Russell O'Connor" <a href=3D"mailto:roconnor@blocks= +tream.com" target=3D"_blank">roconnor@blockstream.com</a>, Bitcoin Protocol= +<br> +> <br> +<br> +> Discussion <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta= +rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> +> <br> +<br> +> Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting<br> +> ("transitory") soft forks)<br> +> Message-ID:<br> +> <a href=3D"mailto:CAGpPWDaeKYABkK%2BStFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1= +A@mail.gmail.com" target=3D"_blank">CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFj= +Ott9W8UPRr1A@mail.gmail.com</a><br> +> <br> +<br> +> Content-Type: text/plain; charset=3D"utf-8"<br> +> <br> +<br> +> @Matt<br> +> <br> +<br> +> > both of which are somewhat frustrating limitations, but not secur= +ity<br> +> <br> +<br> +> limitations, only practical ones.<br> +> <br> +<br> +> So I think the first limitation you mentioned (that if your hot wallet= +'s<br> +> key gets stolen you need) can be legitimately considered a security<br= +> +> limitation. Not because you need to rotate your keys, but because you = +might<br> +> not know your hot wallet key has been stolen. If you unvault an output= + to<br> +> your hot wallet, the thief could be lying in wait, ready to steal thos= +e<br> +> funds upon them landing. At that point, you would then know your hot w= +allet<br> +> key was compromised and could rotate your vault keys in order to preve= +nt<br> +> further theft. However, the fact that there is a clear theft vulnerabi= +lity<br> +> is something I would say should be considered a "security limitat= +ion".<br> +> <br> +<br> +> As you mentioned, this is of course also a security limitation of a ho= +t<br> +> wallet, so this setup definitely has a lot of advantages over a simple= + hot<br> +> wallet. However, if you compare it against a multisig wallet (eg 2 of = +3),<br> +> you can see that while theft of a single key would never result in any= +<br> +> theft in that setup, it could in a CTV vault. The other trade offs the= +re<br> +> are ones of practicality and convenience.<br> +> <br> +<br> +> This isn't to say a CTV vault wouldn't be useful. Just that it= + has<br> +> significant trade offs.<br> +> <br> +<br> +> @Russel<br> +> <br> +<br> +> > the original MES vault .. commits to the destination address duri= +ng<br> +> <br> +<br> +> unvaulting<br> +> <br> +<br> +> I see. Looking at the MES16 paper, OP_COV isn't described clearly = +enough<br> +> for me to understand that it does that. However, I can imagine how it<= +br> +> might do that.<br> +> <br> +<br> +> One possibility is that the intended destination is predetermined and<= +br> +> hardcoded. This wouldn't be very useful, and also wouldn't be = +different<br> +> than how CTV could do it, so I assume that isn't what you envision= +ed this<br> +> doing.<br> +> <br> +<br> +> I can imagine instead that the definition of the pattern could be spec= +ified<br> +> as a number indicating the number of stack items in the pattern, follo= +wed<br> +> by that number of stack items. If that's how it is done, I can see= + the user<br> +> inputting an intended destination script (corresponding to the intende= +d<br> +> destination address) which would then be somehow rotated in to the rig= +ht<br> +> spot within the pattern, allowing the pattern to specify the coins<br> +> eventually reaching an address with that script. However, this could b= +e<br> +> quite cumbersome, and would require fully specifying the scripts along= + the<br> +> covenant pathways leading to a fair amount of information duplication<= +br> +> (since scripts must be specified both in the covenant and in spending = +the<br> +> subsequent output). Both of these things would seem to make OP_COV in<= +br> +> practice quite an expensive opcode to spend with. It also means that, = +since<br> +> the transactor must fully specify the script, its not possible to take= +<br> +> advantage of taproot's script hiding capabilities (were it to send= + to a<br> +> taproot address).<br> +> <br> +<br> +> However, my assumptions might be incorrect. If you think OP_COV would = +be a<br> +> useful opcode, I would encourage you to write up a complete specificat= +ion.<br> +> <br> +<br> +> > What ways can we build a secured vault that commits to the destin= +ation<br> +> <br> +<br> +> address?<br> +> <br> +<br> +> Some kind of passed-through state allows doing this. With OP_COV (if m= +y<br> +> assumptions above are correct), the intended destination can be passed= +<br> +> through the output script pattern(s). With my own proposed<br> +> op_pushoutputstack<br> +> <a href=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-vaults= +/blob/main/pos/bip-pushoutputstack.md" rel=3D"noreferrer" target=3D"_blank"= +>https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/= +bip-pushoutputstack.md</a>,<br> +> <br> +<br> +> state is passed as an attachment on the output more directly. Curious = +what<br> +> you think about that proposal.<br> +> <br> +<br> +> > Are there elegant ways of building secure vaults by using CTV plu= +s<br> +> <br> +<br> +> something else.<br> +> <br> +<br> +> Since CTV predefines all the transactions that can happen under its<br= +> +> control, passed state like this can't help because any dynamic sta= +te would<br> +> change the template and render the CTV transaction invalid. I don'= +t see any<br> +> way of solving this problem for CTV.<br> +> <br> +<br> +> I'm curious how you think op_cat could enable this with CTV (other= + than the<br> +> cat+schnorr tricks that don't require CTV at all).<br> +> <br> +<br> +> <br> +<br> +> <br> +<br> +> On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev &= +lt;<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +> <br> +<br> +> > Okay, Matt explained to me the intended application of CTV vaults= + off<br> +> > list, so I have a better understanding now.<br> +> > <br> +<br> +> > The CTV vault scheme is designed as an improvement over the tradi= +tional<br> +> > management of hot-wallets and cold-wallets. The CTV vault is logi= +cally on<br> +> > the "cold-side" and lets funds be sent from the "c= +old" side to one's own<br> +> > the hot wallet after the unvaulting delay. In this case, the hot = +wallet<br> +> > funds are always at risk, so it isn't unexpected that those f= +unds could be<br> +> > stolen. After all, that is how hot wallets are today. The advanta= +ge is<br> +> > that funds can be moved from the "cold" side without ne= +eding to dig out the<br> +> > cold keys.<br> +> > <br> +<br> +> > The MES vault scheme applies to a different scenario. In the MES = +case it<br> +> > is the hot funds are inside the vault, and it is the hot key that= + unvaults<br> +> > the funds and sends them to customer's addresses after a dela= +y. If the<br> +> > hot-key is used in any unauthorised way, then funds can be sent t= +o the<br> +> > address of the cold key (the MES vault actually does something fa= +ncy in<br> +> > case of recovery, but it could be adapted to simply send funds to= + a cold<br> +> > wallet).<br> +> > <br> +<br> +> > The MES vault lie somewhere between "better" and "= +different" when compared<br> +> > to the CTV vault. If one is unwilling to use the MES vault on the= + hot side<br> +> > and have every withdrawl vetted, then, while you could use the ME= +S design<br> +> > on the cold side like the CTV vault, it wouldn't really offer= + you any<br> +> > advantages over a CTV vault. However, if you are interested in ma= +naging<br> +> > all your payments through a vault (as I've been imagining) th= +en the CTV<br> +> > vault comes across as ineffective when compared to an MES style v= +ault.<br> +> > <br> +<br> +> > On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <a href=3D"mailto:lf= +-lists@mattcorallo.com" target=3D"_blank">lf-lists@mattcorallo.com</a><br> +> > wrote:<br> +> > <br> +<br> +> > > Still trying to make sure I understand this concern, let me = +know if I get<br> +> > > this all wrong.<br> +> > > <br> +<br> +> > > On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wr= +ote:<br> +> > > <br> +<br> +> > > > It's not the attackers only choice to succeed. If a= +n attacker steals<br> +> > > > the hot key, then they have<br> +> > > > the option to simply wait for the user to unvault their= + funds of their<br> +> > > > own accord and then race /<br> +> > > > outspend the users transaction with their own. Indeed, = +this is what we<br> +> > > > expect would happen in the<br> +> > > > dark forest.<br> +> > > <br> +<br> +> > > Right, a key security assumption of the CTV-based vaults wou= +ld be that<br> +> > > you MUST NOT EVER withdraw<br> +> > > more in one go than your hot wallet risk tolerance, but give= +n that your<br> +> > > attack isn't any worse than<br> +> > > simply stealing the hot wallet key immediately after a withd= +raw.<br> +> > > <br> +<br> +> > > It does have the drawback that if you ever get a hot wallet = +key stole you<br> +> > > have to rotate all of your<br> +> > > CTV outputs and your CTV outputs must never be any larger th= +an your hot<br> +> > > wallet risk tolerance<br> +> > > amount, both of which are somewhat frustrating limitations, = +but not<br> +> > > security limitations, only<br> +> > > practical ones.<br> +> > > <br> +<br> +> > > > And that's not even mentioning the issues already n= +oted by the document<br> +> > > > regarding fee management,<br> +> > > > which would likely also benefit from a less constrained= + design for<br> +> > > > covenants.<br> +> > > <br> +<br> +> > > Of course I've always been in favor of a less constraine= +d covenants<br> +> > > design from day one for ten<br> +> > > reasons, but that's a whole other rabbit hole :)<br> +> > <br> +<br> +> > _______________________________________________<br> +> > bitcoin-dev mailing list<br> +> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target= +=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> +> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit= +coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio= +n.org/mailman/listinfo/bitcoin-dev</a><br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--00000000000007a69405dd994c71-- + |