Return-Path: <fresheneesz@gmail.com> Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 94499C002D for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 27 Apr 2022 01:52:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6E041400FD for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 27 Apr 2022 01:52:31 +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: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWEyDkmlmC4I for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 27 Apr 2022 01:52:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by smtp2.osuosl.org (Postfix) with ESMTPS id 08796400D1 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 27 Apr 2022 01:52:29 +0000 (UTC) Received: by mail-ej1-x629.google.com with SMTP id bv19so538722ejb.6 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 26 Apr 2022 18:52:29 -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 :cc; bh=2BC6Y4kz1aMxqL7w0ntWFbqV6pXQCje+T0oQmpePymk=; b=PVtERaxIaTT+6ujY2uBCukr0EMq4rdoqYNF/YBzmY9gSYYLw7EX59F/7MT5DJn0Vig eDqrJE6KfTOTWnF5teInXaBP2pOtQQ1qNHvtLJKPjVtCHDz8aif456msZm0tprwJ74l7 /z8Sd17ZRaDcKYl0f5067s1DIt3S6uztVOp8QMlWHrRqwJXKleee+3YsV5hLZfqxK5Ji vGtxDlmziK8cPYrFgrXtXkD4kjAFgQSLzAyRmOgiMj8cggZkZuINO/aIrRhPeoNTDjog rEQmqn16E8h980Nxyz1Tl3RHCuJCFhS+jCRbzGVxc6hB8CLmre4U1vH02XdOepU8m315 t+Bg== 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=2BC6Y4kz1aMxqL7w0ntWFbqV6pXQCje+T0oQmpePymk=; b=YgVTm1fYD4knUQlrEhPbNftGIDcEh8mLsGRLoo7cVql7EgORdyF2wYvkqwf9qIdqtL W5j12CA4TNZBwnPkI/qGVSZ1Nmbk6K/scKKTuHh+tp9pZ7Odwpf/o4P8nEEVmHotee4P 8iFQb3KZNA5NEJRoSof4LRs08dyTydWUcvHA6DxH6ANPHNtxY1wlnzrnI2tVdipoOPih f3Cijcv9Cp+/L6SpR6jtBvXtf4TLxkdkbNZx+cQzjb/v4YufcHLFxmtNIb/Ha9oN5shH GVld6P6+pCxGhkVnx6TPHleYzGjjpHWpbmDV17pdJ/Pb+JBkEqf/bo5iAuP1cKml9r3t CgUA== X-Gm-Message-State: AOAM530aG/YC/rt1IjHTnEbRvOZAokHKeuAUkosO42C3se/AuC94iISf K0VBHb8+ux4OsOtDfjx+PuydK4VSTKw3TuG6iZc= X-Google-Smtp-Source: ABdhPJxegmlTNJJH4HRR1ueSe60JHNZtSGAVzOifsRrbrrIzn0pWaWfjtDesoFiRgjzzc7/79AeF6b/Z0QiUQjMWYAg= X-Received: by 2002:a17:907:1c87:b0:6f0:29ea:cc01 with SMTP id nb7-20020a1709071c8700b006f029eacc01mr24237649ejc.671.1651024348008; Tue, 26 Apr 2022 18:52:28 -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> In-Reply-To: <CAMZUoKnmvjOXq8NY_DnBQnRp6snxZ7hDCF1XQCndwCcp1rBO3Q@mail.gmail.com> From: Billy Tetrud <billy.tetrud@gmail.com> Date: Tue, 26 Apr 2022 20:52:12 -0500 Message-ID: <CAGpPWDZf8aFWMrWp5B6CJdCp-ntq_Gjk+ngZH4yg039P1B0Pgg@mail.gmail.com> To: "Russell O'Connor" <roconnor@blockstream.com> Content-Type: multipart/alternative; boundary="000000000000c7565405dd990f82" X-Mailman-Approved-At: Wed, 27 Apr 2022 08:09:15 +0000 Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 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 01:52:31 -0000 --000000000000c7565405dd990f82 Content-Type: text/plain; charset="UTF-8" @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. > --000000000000c7565405dd990f82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">@Russell<br><div>> OP_PUBKEY, and OP_PUBKEYHASH as wild= cards</div><div><br></div><div>Ah I see. Very interesting. Thanks for clari= fying.=C2=A0<br><br>@Nadav<br></div><div>> You can have a CTV vault wher= e 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 still have all the downsides you=C2=A0get w= ith a multisig wallet. The whole point of a wallet vault is that you can ge= t the security of a multisig wallet without having to sign using as many ke= ys.=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@blocks= tream.com</a>> wrote:<br></div><blockquote class=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 class=3D"gmail_quote"><div dir=3D"ltr" cla= ss=3D"gmail_attr">On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <<a href= =3D"mailto:billy.tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com= </a>> wrote:<br></div><blockquote class=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 paper, OP_COV isn't described clea= rly enough for me to understand that it does that. However, I can imagine h= ow it *might* do that.=C2=A0</div><div><br></div><div>One possibility is th= at 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.</div><div><= br></div><div>I can imagine instead that the definition of the pattern coul= d be specified as a number indicating the number of stack items in the patt= ern, 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 t= he covenant pathways leading to a fair amount of information duplication (s= ince scripts must be specified both in the covenant and in spending the sub= sequent 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 tra= nsactor must fully specify the script, its not possible to take advantage o= f taproot's=C2=A0script hiding capabilities (were it to send to a tapro= ot address). <br></div></div></blockquote><div><br></div><div>So my underst= anding 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.=C2=A0 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-b= yte push value.</div><div><br></div><div>If you just used COV by itself, th= en these wildcards would be third-party malleable, but you also have to sig= n the transaction with the hot wallet key, which removes the malleability.<= /div><div><br></div><div>No need to rotate anything into place.<br></div><d= iv><br></div><div>I hope this makes sense.</div></div></div> </blockquote></div> --000000000000c7565405dd990f82--