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"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting
 ("transitory") soft forks)
Precedence: list

--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--