diff options
| author | Nadav Ivgi <nadav@shesek.info> | 2022-04-29 02:14:03 +0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-28 23:14:17 +0000 |
| commit | b09b415914c2ab32079b4a3fd7c6b2ea4ea0240e (patch) | |
| tree | 4d08bdc02c2e8d363b3ecaf11a6d797d3888bb0f | |
| parent | 2383ad232ad82308bef1942f7cd406ed93319d38 (diff) | |
| download | pi-bitcoindev-b09b415914c2ab32079b4a3fd7c6b2ea4ea0240e.tar.gz pi-bitcoindev-b09b415914c2ab32079b4a3fd7c6b2ea4ea0240e.zip | |
Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
| -rw-r--r-- | f8/17370240d5ba0ed8dc627f64d0a45d118a258c | 303 |
1 files changed, 303 insertions, 0 deletions
diff --git a/f8/17370240d5ba0ed8dc627f64d0a45d118a258c b/f8/17370240d5ba0ed8dc627f64d0a45d118a258c new file mode 100644 index 000000000..ef71cee2b --- /dev/null +++ b/f8/17370240d5ba0ed8dc627f64d0a45d118a258c @@ -0,0 +1,303 @@ +Return-Path: <nadav@shesek.info> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 47F12C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 28 Apr 2022 23:14:17 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 317E8611AE + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 28 Apr 2022 23:14:17 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.697 +X-Spam-Level: +X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_NONE=0.001] autolearn=no autolearn_force=no +Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=neutral + reason="invalid (public key: not available)" header.d=shesek.info +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 OKDbHS_55B73 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 28 Apr 2022 23:14:15 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com + [IPv6:2607:f8b0:4864:20::d30]) + by smtp3.osuosl.org (Postfix) with ESMTPS id ADE69611AA + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 28 Apr 2022 23:14:15 +0000 (UTC) +Received: by mail-io1-xd30.google.com with SMTP id z18so7717504iob.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 28 Apr 2022 16:14:15 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shesek.info; s=shesek; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=VcVY+rznj0yd8QOZkMUuU0XyRzY++Dwh3JQyNXusfXc=; + b=m5fdNeGMDWLGDU0f5QuKFuVmgF1yLRuyUM6rHxJQUwliSbn+48kEFmQw3zF8eqnTyY + CpL1BxRskgXvKoMJDnBWZE1j7nonI6dumZzN3UZa4B8IhSGq9J2bNvsYMquZxE2xYeAW + 6T2FIjQjZ4lb+3XWIGujEcQW9Hi2dlduL5ydQ= +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:cc; + bh=VcVY+rznj0yd8QOZkMUuU0XyRzY++Dwh3JQyNXusfXc=; + b=qZmu383Aaom2d2dfGOeHY4I0oUDxHY8pxHq/cUhpjiNK6avUgGlDy97crca/4NQ/OS + DR62jAHmgaDYF0H6SUzIey5H3yQ3i9S5Y9huO192kPoEEDvVcZBaZnKPZK+xQhQHcOkL + hGlZENim0J2+M2taOjE1BC/r74Y3utlqmkGBZttda9y/a/SF5bWf1tBm9piBUwIbADba + mgbQdKLYIQyJ4iznJrMye+VSSybr5BjtGQUuQvOB96DJkaSjHe5Bi8pzDCWUfkcPYSxZ + YKKTg9D9vYhOJlk8+eamnTdrCXhJyC7nFtWRW8VhEqWrsKf51xVOscSvNqsbu//V1nC6 + yz8g== +X-Gm-Message-State: AOAM532f4nXRYUqIYltB1LImGiYOwOFE4rOPzq+WiihVjP4E7w9hH59x + oo9c9inXv1IMexf8CvEY9etlCHOnO9/jBtsaklMb+g== +X-Google-Smtp-Source: ABdhPJxZzH7hA6UYjToMJuxYPaMod1dgV9BEez7KX6r1ZckO4HbwDkMyqYv5CHm1QSgbQULq7OJP6wFsfx5pfDL+mBw= +X-Received: by 2002:a05:6638:2483:b0:32a:b172:7166 with SMTP id + x3-20020a056638248300b0032ab1727166mr14865289jat.224.1651187654593; Thu, 28 + Apr 2022 16:14:14 -0700 (PDT) +MIME-Version: 1.0 +References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> + <d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com> + <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org> + <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com> + <CAPfvXfJe6YHViquT8i+Kq2QUjZDZyUq24nKkJd2a6dYKgygxNQ@mail.gmail.com> + <CAMZUoK=GONdGwj34PcqjV5sFJBg+XqiSOHFk4aQoTgy00YFG=Q@mail.gmail.com> + <48a4546c-85b3-e9ff-83b5-60ba4eae2c76@mattcorallo.com> + <CAMZUoKniYvmtYXOOOqpDGyaEyzG5DObwbFQhvaYkndSnJUmvkg@mail.gmail.com> + <CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1A@mail.gmail.com> + <CAMZUoKnmvjOXq8NY_DnBQnRp6snxZ7hDCF1XQCndwCcp1rBO3Q@mail.gmail.com> + <CAGpPWDZf8aFWMrWp5B6CJdCp-ntq_Gjk+ngZH4yg039P1B0Pgg@mail.gmail.com> +In-Reply-To: <CAGpPWDZf8aFWMrWp5B6CJdCp-ntq_Gjk+ngZH4yg039P1B0Pgg@mail.gmail.com> +From: Nadav Ivgi <nadav@shesek.info> +Date: Fri, 29 Apr 2022 02:14:03 +0300 +Message-ID: <CAGXD5f2CAHr9QM5SuqRLtZZ6m80PyikEO59kx1xNrOfbOuB4LA@mail.gmail.com> +To: Billy Tetrud <billy.tetrud@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="0000000000009c22d805ddbf15b6" +X-Mailman-Approved-At: Fri, 29 Apr 2022 07:13:13 +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: Thu, 28 Apr 2022 23:14:17 -0000 + +--0000000000009c22d805ddbf15b6 +Content-Type: text/plain; charset="UTF-8" + +> The whole point of a wallet vault is that you can get the security of a +multisig wallet without having to sign using as many keys. + +In my view, the point of a vault is the ability to keep your primary wallet +keys in *highly* deep cold storage (e.g. metal backup only, not loaded on +any HW wallets, with geographically distributed shares and a slow +cumbersome process for collecting them), which is made possible because +you're not supposed to actually need to use these keys, except for the +extraordinary (typically once or twice in a lifetime?) circumstances of +theft. + +The user can then use a warmer model for the keys they use more frequently +for the covenant-encumbered two-step spending. But these warmer keys can +themselves also be cold and/or multi-sig, yet more accessible. For example, +a 2-of-2 with standard hardware wallets you have within reach in your +apartment. + +So if you have a cold wallet that you anticipate having to access once +every, say, 2-3 months, no matter what scheme you currently use to secure +it, you can improve your overall security by using that same scheme for +securing the covenant-encumbered keys, then use a colder more secure scheme +for your primary keys under the assumption that you'll only have to access +them at most once every several years. + +IIUC what you were describing is that you can use your regular multisig +scheme for the primary cold wallet keys, and a 1-of-1 for the +covenant-encumbered keys (which can even be hot on your phone etc). + +Both approaches are valid, one gets you more security while the other gets +you more convenience. And there is of course a whole range of options that +can be chosen in between that gets you some of both. + +shesek + +On Wed, Apr 27, 2022 at 11:09 AM Billy Tetrud via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> @Russell +> > OP_PUBKEY, and OP_PUBKEYHASH as wildcards +> +> Ah I see. Very interesting. Thanks for clarifying. +> +> @Nadav +> > You can have a CTV vault where the hot key signer is a multisig to get +> the advantages of both. +> +> Yes, you can create a CTV vault setup where you unvault to a multisig +> wallet, but you don't get the advantages of both. Rather you get none of +> the advantages and still have all the downsides you get with a multisig +> wallet. The whole point of a wallet vault is that you can get the security +> of a multisig wallet without having to sign using as many keys. +> +> On Mon, Apr 25, 2022 at 5:28 PM Russell O'Connor <roconnor@blockstream.com> +> wrote: +> +>> On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tetrud@gmail.com> +>> wrote: +>> +>>> @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). +>>> +>> +>> So my understanding is that the COV proposal in MES lets you check that +>> the output's scriptPubKey matches the corresponding script item from the +>> stack, but the script item's value additionally allows some wildcard +>> values. In particular, it makes use of the otherwise reserved opcodes +>> OP_PUBKEY, and OP_PUBKEYHASH as wildcards representing any, let's say, +>> 32-byte or 20-byte push value. +>> +>> If you just used COV by itself, then these wildcards would be third-party +>> malleable, but you also have to sign the transaction with the hot wallet +>> key, which removes the malleability. +>> +>> No need to rotate anything into place. +>> +>> I hope this makes sense. +>> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--0000000000009c22d805ddbf15b6 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>> The whole point of a wallet vault is that you ca= +n=20 +get the security of a multisig wallet without having to sign using as=20 +many keys.</div><div><br></div><div>In my view, the point of a vault is the= + ability to keep your primary wallet keys in <i>highly</i> deep cold storag= +e (e.g. metal backup only, not loaded on any HW wallets, with geographicall= +y distributed shares and a slow cumbersome process for collecting them), wh= +ich is made possible because you're not supposed to actually need to us= +e these keys, except for the extraordinary (typically once or twice in a li= +fetime?) circumstances of theft.</div><div><br></div><div>The user can then= + use a warmer model for the keys they use more frequently for the covenant-= +encumbered two-step spending. But these warmer keys can themselves also be = +cold and/or multi-sig, yet more accessible. For example, a 2-of-2 with stan= +dard hardware wallets you have within reach in your apartment.</div><div><b= +r></div><div>So if you have a cold wallet that you anticipate having to acc= +ess once every, say, 2-3 months, no matter what scheme you currently use to= + secure it, you can improve your overall security by using that same schem= +e for securing the covenant-encumbered keys, then use a colder more secure = +scheme for your primary keys under the assumption that you'll only have= + to access them at most once every several years.<br></div><div><br></div><= +div>IIUC what you were describing is that you can use your regular multisig= + scheme for the primary cold wallet keys, and a 1-of-1 for the covenant-enc= +umbered keys (which can even be hot on your phone etc).</div><div><br></div= +><div>Both approaches are valid, one gets you more security while the other= + gets you more convenience. And there is of course a whole range of options= + that can be chosen in between that gets you some of both.<br></div><div><b= +r></div><div>shesek<br></div></div><br><div class=3D"gmail_quote"><div dir= +=3D"ltr" class=3D"gmail_attr">On Wed, Apr 27, 2022 at 11:09 AM Billy Tetrud= + via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or= +g">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquot= +e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= +olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">@Russell<br><div>&= +gt; OP_PUBKEY, and OP_PUBKEYHASH as wildcards</div><div><br></div><div>Ah I= + see. Very interesting. Thanks for clarifying.=C2=A0<br><br>@Nadav<br></div= +><div>> You can have a CTV vault where the hot key signer is a multisig = +to get the advantages of both.</div><div><br></div><div>Yes, you can create= + a CTV vault setup where you unvault to a multisig wallet, but you don'= +t get the advantages of both. Rather you get none of the advantages and sti= +ll have all the downsides you=C2=A0get with a multisig wallet. The whole po= +int of a wallet vault is that you can get the security of a multisig wallet= + without having to sign using as many keys.=C2=A0</div></div><br><div class= +=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 25, 2022= + at 5:28 PM Russell O'Connor <<a href=3D"mailto:roconnor@blockstream= +.com" target=3D"_blank">roconnor@blockstream.com</a>> wrote:<br></div><b= +lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= +ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class= +=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr 24, 2022= + at 7:04 PM Billy Tetrud <<a href=3D"mailto:billy.tetrud@gmail.com" targ= +et=3D"_blank">billy.tetrud@gmail.com</a>> wrote:<br></div><blockquote cl= +ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid= + rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>@Russel<br></div>= +<div>> the original MES vault ..=C2=A0commits to the destination address= + during unvaulting</div><div><br></div><div>I see. Looking at the MES16 pap= +er, OP_COV isn't described clearly enough for me to understand that it = +does that. However, I can imagine how it *might* do that.=C2=A0</div><div><= +br></div><div>One possibility is that the intended destination is predeterm= +ined 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.</div><div><br></div><div>I can imagine instead that= + the definition of the pattern could be specified as a number indicating th= +e number of stack items in the pattern, followed by that number of stack it= +ems. If that's how it is done, I can see the user inputting an intended= + destination script (corresponding to the intended destination address) whi= +ch would then be somehow rotated in to the right spot within the pattern, a= +llowing the pattern to specify the coins eventually reaching an address wit= +h that script. However, this could be quite cumbersome, and would require f= +ully specifying the scripts along the covenant pathways leading to a fair a= +mount of information duplication (since scripts must be specified both in t= +he covenant and in spending the subsequent output). Both of these things wo= +uld 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, i= +ts not possible to take advantage of taproot's=C2=A0script hiding capab= +ilities (were it to send to a taproot address). <br></div></div></blockquot= +e><div><br></div><div>So my understanding is that the COV proposal in MES l= +ets you check that the output's scriptPubKey matches the corresponding = +script item from the stack, but the script item's value additionally al= +lows some wildcard values.=C2=A0 In particular, it makes use of the otherwi= +se reserved opcodes OP_PUBKEY, and OP_PUBKEYHASH as wildcards representing = +any, let's say, 32-byte or 20-byte push value.</div><div><br></div><div= +>If you just used COV by itself, then these wildcards would be third-party = +malleable, but you also have to sign the transaction with the hot wallet ke= +y, which removes the malleability.</div><div><br></div><div>No need to rota= +te anything into place.<br></div><div><br></div><div>I hope this makes sens= +e.</div></div></div> +</blockquote></div> +_______________________________________________<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> + +--0000000000009c22d805ddbf15b6-- + |