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