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
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id EA062C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Mar 2023 16:07:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id C53CC80E8E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Mar 2023 16:07:52 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C53CC80E8E
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=CLRZtdU4
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Zo8qYAPLoIVO
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Mar 2023 16:07:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5095480E78
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
[IPv6:2a00:1450:4864:20::531])
by smtp1.osuosl.org (Postfix) with ESMTPS id 5095480E78
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Mar 2023 16:07:51 +0000 (UTC)
Received: by mail-ed1-x531.google.com with SMTP id ec29so9920233edb.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 06 Mar 2023 08:07:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20210112; t=1678118869;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=O0XFbo02IC/faotjgZfJb21wyoCDhYIls0Oxw3KxrvE=;
b=CLRZtdU4zirjVxaODlww2j5qCZbZIAdWn1SL20ojyiykyQqD4Wh6Qdz8FyjXkPRln0
NTyhXHzH58/0apg5TcgRmw3SW3RoaSc4/xGVvprcbssCvBP8eSTIbtMgfadYws5uOqDP
j64mZBvjexhhy+GuUnWg5cPQ+X/iwArJFUy4HNvfo2EY7vI4KJ81oCzA8GtRG7vzf16Q
XyVvt8z4HCVgLgQbC3SRkY+dh+kQrDyxJoUJopyWH1sYw5VktFnksv7g0+/AmxFLiYXv
u2gObzNPT0ijqTSg+CGfeXbJH1xUOgTrbzcSBj2it17Os3px4P1KeQ1SHZlwT8s+kr/m
4ncg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112; t=1678118869;
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=O0XFbo02IC/faotjgZfJb21wyoCDhYIls0Oxw3KxrvE=;
b=6hYdW/oHint8fdLbuEo+adPtPWcsN6vDwrIVl7udHVponED+2CEn89ZChHKaPvDg+w
VT67Kqgpc685YX6iw/GBEr2+3YAubQyTc6Fn4vXyqgZiTdARiog6om5f0t9kK7aH0uXY
V6YM325JCctVH1/NYTkVJRAR1FVIa7cnNWntIlVWmdkl7DPhpCcF/sEeHWsMsfHz4D2B
zKjNWp9sjXoZDRDPePsgGq+esZ4T60v2CKQ77r9KFZVJKCURJXL4tQXsPjhCGLUxFAUU
QahXiqnK8Tjw8WAMI6cUH8qtdZtuI0EAs86/yEefhPIk/Dm8rngEFdn3Bh8WVyDeFi/p
e8Qw==
X-Gm-Message-State: AO0yUKV8F7yC8ts3sDyRlAFntzatzzhBvwcx0GBmNioJ6bsnjCn8qAGV
pt9gEZMWJlrcUcrQfRItHXgSvOcsEp6wB6ybrX4=
X-Google-Smtp-Source: AK7set9odQ2Q1k2ABmYU48hBDmq7bAn5ROPITx8qy6/hRjwKvoLmLZ8fPoOXwhH5SNyaNmMn9qRF1R7Z/+ol7AnupkU=
X-Received: by 2002:a17:907:724f:b0:8b1:3c31:efe6 with SMTP id
ds15-20020a170907724f00b008b13c31efe6mr9024655ejc.3.1678118869312; Mon, 06
Mar 2023 08:07:49 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfJQKb7i8GBvTEvTTz-3dU_5mH8jOv8Nm4Q8gPt=KxrqLQ@mail.gmail.com>
<CAB3F3DveCDz6yy-rd3ttV8+4sMufsvB+9J-qVK95yh9aLYX+Mw@mail.gmail.com>
<ZAAqIZZO1KK32Th9@erisian.com.au>
<CAB3F3DtGpVHkyT_=KLS42rvdP=dgnMvChhR1Rs0BHO5yOEabmw@mail.gmail.com>
<CAPfvXf+4iX0h-nSuyTai_VvJHkDvAyKtgSk6DsaEwE8N3wnYEg@mail.gmail.com>
In-Reply-To: <CAPfvXf+4iX0h-nSuyTai_VvJHkDvAyKtgSk6DsaEwE8N3wnYEg@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Mon, 6 Mar 2023 11:07:38 -0500
Message-ID: <CAB3F3DvXon1tawj6tdLiHY-kkDSXn5P7yn3Wjwz6Z=UZYXxLTQ@mail.gmail.com>
To: "James O'Beirne" <james.obeirne@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000018a8c405f63d7f78"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] BIP for OP_VAULT
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, 06 Mar 2023 16:07:53 -0000
--00000000000018a8c405f63d7f78
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi James,
I think everything except the hinted "withdrawal authorization" is spot on.
For withdrawal authorization, I think we'll have to go deeper into the TLUV
direction
as AJ suggested for at least a couple reasons:
1) You need the withdrawal authorization committed at deposit time
2) You need to make sure cheeky opcodes cannot be prepended to the script
at spend time
OP_FORWARD_LEAF_UPDATE(OP_FLU) seems to fit the bill, at the cost of maybe
adding another opcode for "refunds" as he notes.
Cheers,
Greg
On Mon, Mar 6, 2023 at 10:25=E2=80=AFAM James O'Beirne <james.obeirne@gmail=
.com>
wrote:
> I'm glad to see that Greg and AJ are forming a habit of hammering
> this proposal into shape. Nice work fellas.
>
> To summarize:
>
> What Greg is proposing above is to in essence TLUV-ify this proposal.
>
> I.e. instead of relying on hashed commitments and recursive script
> execution (e.g. <trigger-sPK-hash> + later presentation of preimage
> script for execution), OP_VAULT would instead move through its
> withdrawal process by swapping out tapleaf contents according to
> specialized rules. If this is opaque (as it was to me), don't fret -
> I'll describe it below in the "mechanics" section.
>
>
> The benefits of this TLUVification are
>
> - we can avoid any nested/recursive script execution. I know the
> recursive stuff rankles some greybeards even in spite of it being
> bounded to a single call. I'm not sure I share the concern but
> maintaining the status quo seems good.
>
> - the spec is easier to reason about, more or less. The opcodes
> introduced don't have variadic witness requirements, and each opcode
> is only consumed in a single way.
>
> - there's less general indirection. Instead of saying "okay, here's the
> hash of the script I'm going to use to authorize trigger
> transactions," we're just outright including the trigger auth script
> in the tapleaf at the birth of the vault as regular 'ol script that is
> evaluated before execution of the OP_VAULT instruction.
>
> Similarly, instead of relying on an implicit rule that an OP_VAULT can
> be claimed by a recovery flow, we're relying on a specific tapleaf that
> facilitates that recovery with OP_VAULT_RECOVER, described below.
>
> Basically, OP_VAULT would just be implemented in a way that feels
> more native to Taproot primitives.
>
> Greg also introduces different opcodes to facilitate consistent
> witness structure, rather than the variable ones we have now
> since OP_VAULT and OP_UNVAULT can each be spent in two different
> contexts. I've changed those a little here; instead of the three general
> ones Greg gave, we whittled it down to two: OP_VAULT and
> OP_VAULT_RECOVER.
>
>
> So I think that, barring significant implementation complexity - which
> I'll find out about soon and don't expect - this is a good change to the
> proposal. As Greg noted, it doesn't really change anything about the
> usage or expressiveness... other than the fact that, as a bonus, it
> might allow an optional withdrawal authorization script (i.e. trigger
> output =3D> final target), which could be useful if e.g. some kind of
> size-limiting opcode (e.g. OP_TX_MAXSIZE or something) came around in
> the future as a kind of pinning fix.
>
> If that last bit lost you, don't worry - that is speculative, but the
> point is that this rework composes well with other stuff.
>
>
> # CTV use
>
> Another thing that has dawned on us is that we might as well just reuse
> OP_CHECKTEMPLATEVERIFY for withdrawal target spends. Ben Carmen and
> others realized early on that you can synthesize CTV-like behavior by
> spending to a 0-delay OP_UNVAULT output, so something CTVish has always
> implicitly been a part of the proposal. But CTV is better studied and
> basically as simple as the OP_UNVAULT spend semantics, so the thought is
> that we might as well reuse all the existing work (and scrutiny) from
> CTV.
>
> As a concrete example, an issue with the existing proposal is that the
> existing CTVish OP_UNVAULT behavior has txid malleability, since it
> doesn't commit to nVersion or nLockTime or the input sequences. Using
> CTV solves this issue. Otherwise we'd basically reinvent it - "something
> something convergent evolution."
>
> I think this is a satisfying development, because there's clearly demand
> for CTV use in other contexts (DLC efficiency, e.g.), and if it's
> required behavior for practical vaults, I think pulling in the existing
> BIP-119 that's been worked over for years reduces the conceptual
> surface area added by OP_VAULT.
>
>
> # New mechanics of the proposal
>
> So here I'm going to describe my rendering of Greg and AJ's suggestions.
>
>
> ## Required opcodes
>
> - OP_VAULT: spent to trigger withdrawal
> - OP_VAULT_RECOVER: spent to recover
> - OP_CHECKTEMPLATEVERIFY: spent into final withdrawal target
>
>
> Creating an initial deposit
> ---------------------------
>
> For each vault, vaulted coins are spent to an output with the taproot
> structure
>
> taproot(internal_key, {$recovery_leaf, $trigger_leaf, ...})
>
> where
>
> internal_key =3D
> unchanged from original proposal (some very safe recovery key)
>
> $recovery_leaf =3D
> [<opt.> <recovery> <auth>] <recovery sPK hash> OP_VAULT_RECOVER
>
> $trigger_leaf =3D
> <trigger> <auth> <script> <spend-delay> OP_VAULT
>
> ... =3D
> other (optional) leaves in the taptree
>
>
> Triggering a withdrawal request
> -------------------------------
>
> To trigger the start of the withdrawal process, an output of the above
> form is spent with a witness that contains
>
> - Taproot control block pointing to $trigger_leaf.
> - <trigger-vout-idx>, indicating the trigger output which must abide
> by the rules given below.
>
>
> ## Output structure
>
> taproot(internal_key, {$recovery_leaf, $expr_withdraw, ...})
>
> where
>
> $recovery_leaf is preserved exactly
> $expr_withdraw =3D
> <spend-delay> OP_CSV OP_DROP <target-ctv-hash> OP_CTV
> ... is preserved exactly
>
>
> (Spoiler: note here that the only thing that is changing is
> s/expr_trigger/expr_withdrawl/ from the initial vault ouput.)
>
> Of course $expr_withdraw *could* be prefixed by an optional "withdrawal
> authorization" script, if some sensible use for that is found.
>
> The validation rules are essentially unchanged from the existing
> proposal:
>
> - The total amount of all OP_VAULT inputs with matching $recovery_leaf
> values must be reflected in output <trigger-vout-idx>
>
> - <trigger-vout-idx> must correspond to an output that is identical to
> the input taptree but with the spent tapleaf (OP_VAULT) swapped out
> for the timelocked CTV constructed using <target-ctv-hash> and
> <spend-delay> as extracted from the spent tapleaf
> - internal_key is preserved
> - the whole rest of the taptree is preserved
> - (this is what ensures the parameters of the vault are forwarded)
>
> All batching, fee management characteristics are the same.
>
>
> Finalizing withdrawal
> ---------------------
>
> Happens via script-path spend to $expr_withdraw, i.e. a timelocked
> OP_CTV.
>
>
> Recovery
> --------
>
> Can happen from any of the above outputs using the $recovery_leaf
> script path in a way very similar to the existing OP_VAULT proposal.
>
>
> ---
>
> To reiterate, all aspects of the existing OP_VAULT proposal are either
> preserved or improved upon in terms of malleability reduction,
> composability, and flexibility. So big thanks to AJ and Greg.
>
> I'll undertake implementing these changes in the coming days to verify
> that they are, as expected, workable.
>
> James
>
--00000000000018a8c405f63d7f78
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi James,<div><br></div><div>I think everything except the=
hinted "withdrawal authorization" is spot on.</div><div><br></di=
v><div>For withdrawal authorization, I think we'll have to go deeper in=
to the TLUV direction</div><div>as AJ suggested for at least a couple reaso=
ns:</div><div><br></div><div>1) You need the withdrawal authorization commi=
tted at deposit time</div><div>2) You need to make sure cheeky opcodes=C2=
=A0cannot be prepended to the script at spend time</div><div><br></div><div=
>OP_FORWARD_LEAF_UPDATE(OP_FLU) seems to fit the bill, at the cost of maybe=
adding another opcode for "refunds" as he notes.</div><div><br><=
/div><div>Cheers,</div><div>Greg</div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 6, 2023 at 10:25=E2=80=AF=
AM James O'Beirne <<a href=3D"mailto:james.obeirne@gmail.com">james.=
obeirne@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);p=
adding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">I'm glad to see that=
Greg and AJ are forming a habit of hammering=C2=A0</div><div dir=3D"ltr">t=
his proposal into shape. Nice work fellas.<br><br>To summarize:<br><br>What=
Greg is proposing above is to in essence TLUV-ify this proposal.<br><br>I.=
e. instead of relying on hashed commitments and recursive script<br>executi=
on (e.g. <trigger-sPK-hash> + later presentation of preimage<br>scrip=
t for execution), OP_VAULT would instead move through its<br>withdrawal pro=
cess by swapping out tapleaf contents according to<br>specialized rules. If=
this is opaque (as it was to me), don't fret -<br>I'll describe it=
below in the "mechanics" section.<br><br><br>The benefits of thi=
s TLUVification are<br><br>- we can avoid any nested/recursive script execu=
tion. I know the<br>=C2=A0 recursive stuff rankles some greybeards even in =
spite of it being<br>=C2=A0 bounded to a single call. I'm not sure I sh=
are the concern but <br>=C2=A0 maintaining the status quo seems good.<br><b=
r>- the spec is easier to reason about, more or less. The opcodes<br>=C2=A0=
introduced don't have variadic witness requirements, and each opcode<b=
r>=C2=A0 is only consumed in a single way.<br><br>- there's less genera=
l indirection. Instead of saying "okay, here's the<br>=C2=A0 hash =
of the script I'm going to use to authorize trigger<br>=C2=A0 transacti=
ons," we're just outright including the trigger auth script<br>=C2=
=A0 in the tapleaf at the birth of the vault as regular 'ol script that=
is<br>=C2=A0 evaluated before execution of the OP_VAULT instruction. <br><=
br>=C2=A0 Similarly, instead of relying on an implicit rule that an OP_VAUL=
T can<br>=C2=A0 be claimed by a recovery flow, we're relying on a speci=
fic tapleaf that<br>=C2=A0 facilitates that recovery with OP_VAULT_RECOVER,=
described below.<br><br>Basically, OP_VAULT=C2=A0would just be implemented=
in a way that feels<br>more native to Taproot primitives.<br><br>Greg also=
introduces different opcodes to facilitate consistent<br>witness structure=
, rather than the variable ones we have now<br>since OP_VAULT and OP_UNVAUL=
T can each be spent in two different<br>contexts. I've changed those a =
little here; instead of the three general<br>ones Greg gave, we whittled it=
down to two: OP_VAULT and<br>OP_VAULT_RECOVER.<br><br><br>So I think that,=
barring significant implementation complexity - which<br>I'll find out=
about soon and don't expect - this is a good change to the<br>proposal=
. As Greg noted, it doesn't really change anything about the<br>usage o=
r expressiveness... other than the fact that, as a bonus, it<br>might allow=
an optional withdrawal authorization script (i.e. trigger<br>output =3D>=
; final target), which could be useful if e.g. some kind of<br>size-limitin=
g opcode (e.g. OP_TX_MAXSIZE or something) came around in<br>the future as =
a kind of pinning fix.<br><br>If that last bit lost you, don't worry - =
that is speculative, but the<br>point is that this rework composes well wit=
h other stuff.<br><br><br># CTV use<br><br>Another thing that has dawned on=
us is that we might as well just reuse<br>OP_CHECKTEMPLATEVERIFY for withd=
rawal target spends. Ben Carmen and<br>others realized early on that you ca=
n synthesize CTV-like behavior by<br>spending to a 0-delay OP_UNVAULT outpu=
t, so something CTVish has always<br>implicitly been a part of the proposal=
. But CTV is better studied and<br>basically as simple as the OP_UNVAULT sp=
end semantics, so the thought is<br>that we might as well reuse all the exi=
sting work (and scrutiny) from<br>CTV.<br><br>As a concrete example, an iss=
ue with the existing proposal is that the<br>existing CTVish OP_UNVAULT beh=
avior has txid malleability, since it<br>doesn't commit to nVersion or =
nLockTime or the input sequences. Using<br>CTV solves this issue. Otherwise=
we'd basically reinvent it - "something<br>something convergent e=
volution."<br><br>I think this is a satisfying development, because th=
ere's clearly demand<br>for CTV use in other contexts (DLC efficiency, =
e.g.), and if it's<br>required behavior for practical vaults, I think p=
ulling in the existing<br>BIP-119 that's been worked over for years red=
uces the conceptual</div><div dir=3D"ltr">surface area added by OP_VAULT.<b=
r><br><br># New mechanics of the proposal<br><br>So here I'm going to d=
escribe my rendering of Greg and AJ's suggestions.<br><br><br>## Requir=
ed opcodes<br><br>- OP_VAULT: spent to trigger withdrawal<br>- OP_VAULT_REC=
OVER: spent to recover<br>- OP_CHECKTEMPLATEVERIFY: spent into final withdr=
awal target<br><br><br>Creating an initial deposit<br>---------------------=
------<br><br>For each vault, vaulted coins are spent to an output with the=
taproot<br>structure<br><br>=C2=A0 taproot(internal_key, {$recovery_leaf, =
$trigger_leaf, ...})<br><br>where<br><br>=C2=A0 internal_key =3D <br>=C2=A0=
=C2=A0 unchanged from original proposal (some very safe recovery key)<br><=
br>=C2=A0 $recovery_leaf =3D <br>=C2=A0 =C2=A0 [<opt.> <recovery&g=
t; <auth>] <recovery sPK hash> OP_VAULT_RECOVER<br><br>=C2=A0 $=
trigger_leaf =3D <br>=C2=A0 =C2=A0 <trigger> <auth> <script&=
gt; <spend-delay> OP_VAULT<br><br>=C2=A0 ... =3D<br>=C2=A0 =C2=A0 oth=
er (optional) leaves in the taptree<br><br><br>Triggering a withdrawal requ=
est<br>-------------------------------<br><br>To trigger the start of the w=
ithdrawal process, an output of the above<br>form is spent with a witness t=
hat contains <br><br>=C2=A0 - Taproot control block pointing to $trigger_le=
af.<br>=C2=A0 - <trigger-vout-idx>, indicating the trigger output whi=
ch must abide<br>=C2=A0 =C2=A0 by the rules given below.<br><br><br>## Outp=
ut structure<br>=C2=A0 <br>=C2=A0 taproot(internal_key, {$recovery_leaf, $e=
xpr_withdraw, ...})<br><br>where<br><br>=C2=A0 $recovery_leaf is preserved =
exactly<br>=C2=A0 $expr_withdraw =3D <br>=C2=A0 =C2=A0 <spend-delay> =
OP_CSV OP_DROP <target-ctv-hash> OP_CTV<br>=C2=A0 ... is preserved ex=
actly<br><br><br>(Spoiler: note here that the only thing that is changing i=
s<br>s/expr_trigger/expr_withdrawl/ from the initial vault ouput.)<br><br>O=
f course $expr_withdraw *could* be prefixed by an optional "withdrawal=
<br>authorization" script, if some sensible use for that is found.<br>=
<br>The validation rules are essentially unchanged from the existing<br>pro=
posal:<br><br>- The total amount of all OP_VAULT inputs with matching $reco=
very_leaf<br>=C2=A0 values must be reflected in output <trigger-vout-idx=
><br><br>- <trigger-vout-idx> must correspond to an output that is=
identical to<br>=C2=A0 the input taptree but with the spent tapleaf (OP_VA=
ULT) swapped out<br>=C2=A0 for the timelocked CTV constructed using <tar=
get-ctv-hash> and<br>=C2=A0 <spend-delay> as extracted from the sp=
ent tapleaf<br>=C2=A0 - internal_key is preserved<br>=C2=A0 - the whole res=
t of the taptree is preserved<br>=C2=A0 - (this is what ensures the paramet=
ers of the vault are forwarded)<br><br>All batching, fee management charact=
eristics are the same.<br><br><br>Finalizing withdrawal<br>----------------=
-----<br><br>Happens via script-path spend to $expr_withdraw, i.e. a timelo=
cked<br>OP_CTV.<br><br><br>Recovery<br>--------<br><br>Can happen from any =
of the above outputs using the $recovery_leaf<br>script path in a way very =
similar to the existing OP_VAULT proposal.<br><br><br>---<br><br>To reitera=
te, all aspects of the existing OP_VAULT proposal are either<br>preserved o=
r improved upon in terms of malleability reduction,<br>composability, and f=
lexibility. So big thanks to AJ and Greg.<br><br>I'll undertake impleme=
nting these changes in the coming days to verify<br>that they are, as expec=
ted, workable.<br><br>James</div></div>
</blockquote></div>
--00000000000018a8c405f63d7f78--
|