path: root/da/73d314093cfa947f5b091c61f226645a371f27

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 &quot;withdrawal authorization&quot; is spot on.</div><div><br></di=
v><div>For withdrawal authorization, I think we&#39;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 &quot;refunds&quot; 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&#39;Beirne &lt;<a href=3D"mailto:james.obeirne@gmail.com">james.=
obeirne@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);p=
adding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">I&#39;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. &lt;trigger-sPK-hash&gt; + 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&#39;t fret -<br>I&#39;ll describe it=
 below in the &quot;mechanics&quot; 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&#39;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&#39;t have variadic witness requirements, and each opcode<b=
r>=C2=A0 is only consumed in a single way.<br><br>- there&#39;s less genera=
l indirection. Instead of saying &quot;okay, here&#39;s the<br>=C2=A0 hash =
of the script I&#39;m going to use to authorize trigger<br>=C2=A0 transacti=
ons,&quot; we&#39;re just outright including the trigger auth script<br>=C2=
=A0 in the tapleaf at the birth of the vault as regular &#39;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&#39;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&#39;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&#39;ll find out=
 about soon and don&#39;t expect - this is a good change to the<br>proposal=
. As Greg noted, it doesn&#39;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&gt=
; 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&#39;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&#39;t commit to nVersion or =
nLockTime or the input sequences. Using<br>CTV solves this issue. Otherwise=
 we&#39;d basically reinvent it - &quot;something<br>something convergent e=
volution.&quot;<br><br>I think this is a satisfying development, because th=
ere&#39;s clearly demand<br>for CTV use in other contexts (DLC efficiency, =
e.g.), and if it&#39;s<br>required behavior for practical vaults, I think p=
ulling in the existing<br>BIP-119 that&#39;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&#39;m going to d=
escribe my rendering of Greg and AJ&#39;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 [&lt;opt.&gt; &lt;recovery&g=
t; &lt;auth&gt;] &lt;recovery sPK hash&gt; OP_VAULT_RECOVER<br><br>=C2=A0 $=
trigger_leaf =3D <br>=C2=A0 =C2=A0 &lt;trigger&gt; &lt;auth&gt; &lt;script&=
gt; &lt;spend-delay&gt; 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 - &lt;trigger-vout-idx&gt;, 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 &lt;spend-delay&gt; =
OP_CSV OP_DROP &lt;target-ctv-hash&gt; 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 &quot;withdrawal=
<br>authorization&quot; 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 &lt;trigger-vout-idx=
&gt;<br><br>- &lt;trigger-vout-idx&gt; 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 &lt;tar=
get-ctv-hash&gt; and<br>=C2=A0 &lt;spend-delay&gt; 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&#39;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--