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
189
190
191
192
193
194
195
196
197
198
|
Return-Path: <james.obeirne@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 68117C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Jan 2023 13:35:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 507B3405D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Jan 2023 13:35:16 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 507B3405D7
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=pFbhE5C7
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
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 3tDn68memZUW
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Jan 2023 13:35:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 606824014B
Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com
[IPv6:2001:4860:4864:20::2e])
by smtp2.osuosl.org (Postfix) with ESMTPS id 606824014B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Jan 2023 13:35:15 +0000 (UTC)
Received: by mail-oa1-x2e.google.com with SMTP id
586e51a60fabf-14fb7fdb977so12093543fac.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Jan 2023 05:35:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=fDG1iVXjnYX2iutfAZfya2oVCjhZrkvGCevQsz0+Cvo=;
b=pFbhE5C7YEVh+SjK83T51lAMlucKyKXGjt0EfYgsd7BJJj3HU7E8jlTKEAwyjDA1hG
wUsLg8ZcT799ifVCRXal+j7EeGWf0LA9AVJb5+IhDZHGVVNqaXFgsYcn7gqaiAcL+PcU
kRQwwGmc5qP1BnpHmCzWBZ0qyvumFGHqUZMtDAWcGplsMsztsgwBOFalAdykXyrJIaYA
ZctpUfLgJyGfIQMzD/8Du/2Jt3Qr/YNFWkOSX4uDnaVcpmsFsnZ0tZ7Vbizc2er1QnmD
KtGazjJGNgL1E4cDLtsD0MOVEcUhcQE4+ADrh1KdRlifcIvaodjceey4uK1rz5gWb9jO
oH8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=fDG1iVXjnYX2iutfAZfya2oVCjhZrkvGCevQsz0+Cvo=;
b=UNvv4w99jCNPwsdsCIAAVlNOnQzbeXB0oEPDAiH2KCTIbuiGMYFtP0bHONPU1uPTyB
rNrGoYjmQhI3IGjN/4yF/yTv3a94Q/Q87RFp3gWn6gGHFOzngxsVeLXHktlC0vp2aN3h
4MO1dV63HngThR43CE2oYmEo+ivbAWIA0vN8z1u4COrRh5r2NzZyc3Kj87kosg+ilwBd
Lkn7ZOZpVLoic8ri4t7+tgiy/LmM6ULnPkLklcFhp/A8TGcmFI4thP2LLPp+Z9waX4Ht
3O0XF5QjOEglnfEnAhP88l+v4AL9XyKQs1BjrGHDl9ilV3D6424vaTPpLJSEg+JTbIeA
ppUg==
X-Gm-Message-State: AFqh2koQ7avllqkPi7S3VMa+5UZFDyqqvUxj5moHxqg88W/ydkg4Yj0Q
hL+WhdLGh5vA0jVyMresRNq1lHzWivraGLg2XcFxo67H
X-Google-Smtp-Source: AMrXdXsthZg7ahebG+NuPH1QDuGtPAX9n1ojP697gkNyoK6ZVfXJFfmHAb8bbtqOfTXxEzzXIk8gUATwECNe2jCrDRo=
X-Received: by 2002:a05:6870:4b8d:b0:14f:d35e:b7fa with SMTP id
lx13-20020a0568704b8d00b0014fd35eb7famr4548601oab.222.1673357714206; Tue, 10
Jan 2023 05:35:14 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfL65cneOabmxfOzTZq14xN4vXNaGboq_g15-frM14RqGA@mail.gmail.com>
<8Uq3KNRWS_WV393lP9wq820PE8KNK0bhQ7u7hMJhIfdfV3-ZhSI-4q9Mw5P_TXivKtyePE2Exha4rso2yi3iNnLJpUpBQ38lAuwG-lQPVUE=@protonmail.com>
<CAB3F3DsyN_Nj0Fs4LseiwxUE96tFt079qbb0hKBnTBZdyaPcSQ@mail.gmail.com>
<CAPfvXfK=ykkFWEpRruudLBMt-DaUprFcF=XCJvQ65AFEbo0zpg@mail.gmail.com>
In-Reply-To: <CAPfvXfK=ykkFWEpRruudLBMt-DaUprFcF=XCJvQ65AFEbo0zpg@mail.gmail.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Tue, 10 Jan 2023 08:35:04 -0500
Message-ID: <CAPfvXfJSj_CbHW+F4WhrX+NNcEUV14NSKLzRcPR6DqQ0tav5KQ@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000023382605f1e8f4c2"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_VAULT: a new vault proposal
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: Tue, 10 Jan 2023 13:35:16 -0000
--00000000000023382605f1e8f4c2
Content-Type: text/plain; charset="UTF-8"
Greg explained his suggestion to me off-list, and I think it's a good one.
To summarize, consider the normal "output flow" of an expected vault use:
(i) output to be vaulted
=> (ii) OP_VAULT output
=> (iii) OP_UNVAULT "trigger" output
=> (iv) final output
In my existing draft implementation, all outputs aside from (iii), the
OP_UNVAULT trigger, can be P2TR or P2WSH. In other words, those outputs can
hide their true script until spend. In my draft, the OP_UNVAULT trigger had
to be bare so that the script interpreter could inspect part of it for
validity: "does this OP_UNVAULT have the same <recovery-spk-hash> and
<spend-delay> as the OP_VAULT?"
If that output wasn't bare, because the <target-hash> is variable at the
time of OP_UNVAULT output creation, the script interpreter would have no
way of constructing the expected scriptPubKey.
Greg's suggestion would allow that output to be any kind of script. He
suggests to put the <target-hash> onto the witness stack when spending the
OP_VAULT output (and creating the OP_UNVAULT output). If we did that, the
script interpreter could e.g. use a NUMS point (i.e. a publicly known point
with no usable private key) to construct a Taproot configuration that looks
like
tr(NUMS, {<OP_UNVAULT <recovery-key> <spend-delay> <target-hash>})
and check if the scriptPubKey of the proposed OP_UNVAULT output matches
that. This would allow all outputs in vault lifecycles to be P2TR, for
example, which would conceal the operation of the vault - a very nice
feature!
This would also allow the OP_VAULT/OP_UNVAULT opcodes to be implemented as
Taproot-only OP_SUCCESSx opcodes, if that was decided to be preferable.
The problem is how to (and whether to) enable something similar for witness
v0 outputs. For example, if we want the (ii) and (iii) output scripts to
live behind P2WSH. One (kind of hacky) option to enable this is to have the
script interpreter construct the expected OP_UNVAULT scriptPubKey on the
basis of what witness version it sees. For example, if it sees "OP_0 <32
bytes data>", it would use <target-hash> on the witness stack to construct
a fitting P2WSH scriptPubKey that is compatible with the OP_VAULT being
spent, and then match against that. But if it detects "OP_1 <32 bytes
data>", it would do the same process for an expected Taproot-with-NUMS
output.
---
Anyway, sorry if that was more verbose than necessary, but I think it's a
really great suggestion from Greg. I'll look at modifying the
implementation accordingly. I'd be curious to hear what others think as
well.
--00000000000023382605f1e8f4c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Greg explained his suggestion to me off-list, and I think =
it's a good one. To summarize, consider the normal "output flow&qu=
ot; of an expected vault use:<div><br></div><div>(i) output to be vaulted=
=C2=A0</div><div>=C2=A0 =3D> (ii) OP_VAULT output=C2=A0</div><div>=C2=A0=
=C2=A0 =3D> (iii) OP_UNVAULT "trigger" output=C2=A0</div><div=
>=C2=A0 =C2=A0 =C2=A0 =3D> (iv) final output</div><div><br></div><div>In=
my existing draft implementation, all outputs aside from (iii), the OP_UNV=
AULT trigger, can be P2TR or P2WSH. In other words, those outputs can hide =
their true script until spend. In my draft, the OP_UNVAULT trigger had to b=
e bare so that the script interpreter could inspect part of it for validity=
: "does this OP_UNVAULT have the same <recovery-spk-hash> and &l=
t;spend-delay> as the OP_VAULT?"</div><div><br></div><div>If that o=
utput wasn't bare, because the <target-hash> is variable at the t=
ime of OP_UNVAULT output creation, the script interpreter would have no way=
of constructing the expected scriptPubKey.</div><div><br></div><div>Greg&#=
39;s suggestion would allow that output to be any kind of script. He sugges=
ts to put the <target-hash> onto the witness stack when spending the =
OP_VAULT output (and creating the OP_UNVAULT output). If we did that, the s=
cript interpreter could e.g. use a NUMS point (i.e. a publicly known point =
with no usable private key) to construct a Taproot configuration that looks=
like</div><div>=C2=A0=C2=A0</div><div>=C2=A0 tr(NUMS, {<OP_UNVAULT <=
recovery-key> <spend-delay> <target-hash>})</div><div><br></=
div><div>and check if the scriptPubKey of the proposed OP_UNVAULT output ma=
tches that. This would allow all outputs in vault lifecycles to be P2TR, fo=
r example, which would conceal the operation of the vault - a very nice fea=
ture!=C2=A0</div><div><br></div><div>This would also allow the OP_VAULT/OP_=
UNVAULT opcodes to be implemented as Taproot-only OP_SUCCESSx opcodes, if t=
hat was decided to be preferable.</div><div><br></div><div>The problem is h=
ow to (and whether to) enable something similar for witness v0 outputs. For=
example, if we want the (ii) and (iii) output scripts to live behind P2WSH=
. One (kind of hacky) option to enable this is to have the script interpret=
er construct the expected OP_UNVAULT scriptPubKey on the basis of what witn=
ess version it sees. For example, if it sees "OP_0 <32 bytes data&g=
t;", it would use <target-hash> on the witness stack to construc=
t a fitting P2WSH scriptPubKey that is compatible with the OP_VAULT being s=
pent, and then match against that. But if it detects "OP_1 <32 byte=
s data>", it would do the same process for an expected Taproot-with=
-NUMS output.</div><div><br></div><div>---</div><div><br></div><div>Anyway,=
sorry if that was more verbose than necessary, but I think it's a real=
ly great suggestion from Greg. I'll look at modifying the implementatio=
n accordingly. I'd be curious to hear what others think as well.=C2=A0<=
/div><div><br></div></div>
--00000000000023382605f1e8f4c2--
|
