1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
Return-Path: <roconnor@blockstream.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 85623C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Apr 2022 22:28:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 63C56415FD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Apr 2022 22:28:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
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=blockstream-com.20210112.gappssmtp.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 zy3Ptlo5GYdy
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Apr 2022 22:28:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com
[IPv6:2607:f8b0:4864:20::730])
by smtp4.osuosl.org (Postfix) with ESMTPS id D9886415F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Apr 2022 22:28:02 +0000 (UTC)
Received: by mail-qk1-x730.google.com with SMTP id j9so11944164qkg.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Apr 2022 15:28:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20210112.gappssmtp.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=j7Iibqd0KBBtlm7GUWtSCDljHPWu7T6ptpTwhd8xRTQ=;
b=Kv43MJobb6TGjDA2exH2IgIqwa11a0JYce+sx7wrgjo37wvdyPb5w31giK1kzUlpGm
3wCBOmnHY2wfWWAyn/O3jOt8XLLSluHgS/1vy/U+rJojQT8HhP/lvdDifVOs9A/eD7/L
yUdA1za1t+z61GBlQy6JMKyQI/gwEyQS7QgWG8XZkLmrHNxYcaNFAdnOmx8JFjKBxX84
ScpuL7gNsXCvbVptYY2UZaIalHMCdQnMUiSAJSMLD1D/ygVWOOeUuNuA323n0rjVcvsZ
KE+OioO9HyThnFeTNUos7zsvVni2jNsMzVR2F/J6hqYWn57MBLqD7K0nDL6RJkrTY/Mn
0tqg==
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=j7Iibqd0KBBtlm7GUWtSCDljHPWu7T6ptpTwhd8xRTQ=;
b=23uXKQQQNGHydpRIyoSgWdEjT8ooK4VoJK17b6e8XrhU2jwgwvFZ1OSr6khIfitUD/
1YDWsBG+dQeMuOJErYRww0P3H7cnObtS8b+tPMxV1jn/t531tf8IdrGJiYDoWlgK00Ub
JopLkwdcjkBgWEwibPdW7+wAYscpGI5UzTLRumrGkujSU0RxdPdFlSqrsVD8uAVWgsbS
NGyIlc1ELpmFUWKo/GH18rm38VWpKFWgCazT2Qy/iDUuhrt5+H3yVSghW9GXTxfz2EIp
NGDcs/TOTEcxVw8Xuie1JSjYfaOkVr91+bQKgkk5RZ1N30/cVKJfskl89AA6o9N9ppJy
K2Yw==
X-Gm-Message-State: AOAM533LQIaj/rpdY+gAI5qr+X/d6rTNYdTvYsp+8v1dFJQB9Zu3ZBPG
pQ//k2OMdAfPEmeyhse1b4TuDlphTUc76SBtHa/Zwg==
X-Google-Smtp-Source: ABdhPJwrUdWdM6oTwmaMK+NoNfXEAm9mskYwAc2937Z4FCNMio/ZwV0wDMIVYDGJKeV6sDzCfEaKF+ZOa3cChU1ODic=
X-Received: by 2002:a05:620a:12c3:b0:69e:84bb:b470 with SMTP id
e3-20020a05620a12c300b0069e84bbb470mr11335083qkl.180.1650925681538; Mon, 25
Apr 2022 15:28:01 -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>
In-Reply-To: <CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1A@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Mon, 25 Apr 2022 18:27:50 -0400
Message-ID: <CAMZUoKnmvjOXq8NY_DnBQnRp6snxZ7hDCF1XQCndwCcp1rBO3Q@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000cc8b8005dd821667"
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: Mon, 25 Apr 2022 22:28:04 -0000
--000000000000cc8b8005dd821667
Content-Type: text/plain; charset="UTF-8"
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.
--000000000000cc8b8005dd821667
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<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:b=
illy.tetrud@gmail.com">billy.tetrud@gmail.com</a>> wrote:<br></div><bloc=
kquote 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 destinatio=
n address during unvaulting</div><div><br></div><div>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.=C2=A0</d=
iv><div><br></div><div>One possibility is that the intended destination is =
predetermined and hardcoded. This wouldn't be very useful, and also wou=
ldn'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 ins=
tead that the definition of the pattern could be specified as a number indi=
cating 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 add=
ress) which would then be somehow rotated in to the right spot within the p=
attern, allowing the pattern to specify the coins eventually reaching an ad=
dress 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 s=
pend with. It also means that, since the transactor must fully specify the =
script, its not possible to take advantage of taproot's=C2=A0script hid=
ing capabilities (were it to send to a taproot address). <br></div></div></=
blockquote><div><br></div><div>So my understanding is that the COV proposal=
in MES lets you check that the output's scriptPubKey matches the corre=
sponding script item from the stack, but the script item's value additi=
onally allows some wildcard values.=C2=A0 In particular, it makes use of th=
e otherwise reserved opcodes OP_PUBKEY, and OP_PUBKEYHASH as wildcards repr=
esenting 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 thi=
rd-party malleable, but you also have to sign the transaction with the hot =
wallet key, which removes the malleability.</div><div><br></div><div>No nee=
d to rotate anything into place.<br></div><div><br></div><div>I hope this m=
akes sense.</div></div></div>
--000000000000cc8b8005dd821667--
|
