path: root/d3/520f081ff399a0bcfab4de37ed4debe7c21237

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>&gt; 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>&gt; 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&#39;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&#39;Connor &lt;<a=
 href=3D"mailto:roconnor@blockstream.com" target=3D"_blank">roconnor@blocks=
tream.com</a>&gt; 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 &lt;<a href=
=3D"mailto:billy.tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com=
</a>&gt; 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>&gt; 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&#39;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&#39=
;t be very useful, and also wouldn&#39;t be different than how CTV could do=
 it, so I assume that isn&#39;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&#39;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&#39;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&#39;s=
 scriptPubKey matches the corresponding script item from the stack, but the=
 script item&#39;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&#39;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--