path: root/55/c21f13dde784b1498ee95a84201cf40a62236e

Return-Path: <gsanders87@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2FAA2C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Mar 2023 15:06:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 0B89840022
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Mar 2023 15:06:03 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0B89840022
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=YKV+HMmq
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id RDqHcYLMTkCD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Mar 2023 15:06:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6136C40462
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [IPv6:2a00:1450:4864:20::531])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 6136C40462
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Mar 2023 15:06:01 +0000 (UTC)
Received: by mail-ed1-x531.google.com with SMTP id cq23so55173464edb.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 01 Mar 2023 07:06:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=eMcMeRiimUP0GN7xRXj7hNHrcyTeQJ0Zh2I8/RSMFkE=;
 b=YKV+HMmqphKhIeO96mBoofnx9ew7Me/iPVP6z/4ZD0upX191C90YXiQ2IiXcSKdCfx
 XMByX4oPqWnb5hWwgHByFTmInyUvhBRHQXq0VfgFInj9/KABFmloDRML94FKesyj/Srb
 TkJOTj1JnAPdo3TuISoSwn7BRWB0cdQwQzF4zqgjIRLKCMtFINsWy8jSUSu/fFemL2dB
 LVbOfOWH32EO3Ko5bwOkE2KvxXlLy68xOItIkVL7nBlXuJwTQahTlDfVecLhD+YWoEf5
 G4ujK0nbu0W5U9ylcimTXylwdDE7lr1rXU/b4jQfYWP7XHc8iXs74fwGDcedbV4k4E8Y
 u+vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=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=eMcMeRiimUP0GN7xRXj7hNHrcyTeQJ0Zh2I8/RSMFkE=;
 b=fsQ2wb4SuOZUIK9lf5m7KSd/YDfA4ONv5HzNT3yczlL4FJjprC3i1BfxmcSk4yqTpc
 uPJvUWyXa7TP9gsWSdA9AlwgMs7t2uxvZai+MmrtK+H6bkqq9H9bSXJPnmbVDXebNPns
 5akoh8N5JUvloI/RdfTvJIJKFuLTlpV8AIeVgLHgYsOZ5W0ZRWP44rcf3Ptxy5a1SRTT
 Zgtuv0FhvhrR3Xq+Gz2XcwuBQvFBHJ4JHtVJzLxobZyAqv07rjRZljxIpyvuikThAeUf
 Dlc98zSWvD/HwAr6v3XtiAj0sWLOgUyK3ojTohUsn9AzJWd+SMF7nbJo9+7KON9Zmb6A
 2MWg==
X-Gm-Message-State: AO0yUKUT/eVQ/+B+G3JO/6fvwdj1glApDDJsErIsk21zzUnbXNI0Em9v
 gv1MgCCKn2zQMBY/lHLmz40NNeNsWDzqP/88Y00cEUFy6DM=
X-Google-Smtp-Source: AK7set/MjjYeZ6CfTL9q+aMFWmy9fr0GN2Rs2Xq01DbhrhtXqcAi2yWBEGv0aq0SCojBBTwLtQezzgwmA/+Zy5zC1kY=
X-Received: by 2002:a17:906:ca0f:b0:889:8b2f:75d1 with SMTP id
 jt15-20020a170906ca0f00b008898b2f75d1mr3253344ejb.10.1677683159017; Wed, 01
 Mar 2023 07:05:59 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfJQKb7i8GBvTEvTTz-3dU_5mH8jOv8Nm4Q8gPt=KxrqLQ@mail.gmail.com>
In-Reply-To: <CAPfvXfJQKb7i8GBvTEvTTz-3dU_5mH8jOv8Nm4Q8gPt=KxrqLQ@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Wed, 1 Mar 2023 10:05:47 -0500
Message-ID: <CAB3F3DveCDz6yy-rd3ttV8+4sMufsvB+9J-qVK95yh9aLYX+Mw@mail.gmail.com>
To: "James O'Beirne" <james.obeirne@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bd2de805f5d80c26"
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: Wed, 01 Mar 2023 15:06:03 -0000

--000000000000bd2de805f5d80c26
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello James,

First off, thank you for crafting an interesting idea like this that is
aimed at solving a serious problem. I see a lot of excitement about the use
cases, and I think it's worth iterating on.

Attempting to keep the idealized functionality constant, I'd like to
explore a design detour. I'm attempting to decouple the 3 functionalities
of `OP_VAULT` and `OP_UNVAULT` into their constituent functions with names
I just made up.

The goals of this e-mail:

1) Removing variable number of arguments based on values of arguments for
the opcodes.
To me as a spec reader, I find it very difficult to parse what's precisely
happening when. I think the only/last opcode to support this behavior was
OP_CHECKMULTISIG(could be wrong), and now I know another reason why OP_CSA
construct is nicer going forward with taproot.

2) Remove the recursive evaluation functionality used for authentication,
without reducing the efficacy of the targeted solution. Recursive
evaluation has a fraught history in Bitcoin script, makes composing
functionality with tooling likely more difficult, and has a lot of
templated behavior. If we can rely on regular old tapscript to get us where
we need to go, I'd prefer that.

3) Increase legibility of the spec. There's a ton going on, breaking things
up and naming them based on the method rather than the goal may help here.

4) Not (greatly) increase the expressiveness of the proposal. It's a
targeted proposal, and I'd like to respect that. These covenant opcodes are
intended to be drop-in replacements for the OP_(UN)VAULT opcodes.

To recap, there are three things happen in idealized OP_VAULT scenario:
1) Money comes out, then has to wait (trigger transaction)
2) Money waits long enough, then withdrawals to dynamic set of outputs that
are declared at trigger time (withdrawal transaction)
3) Money to single specified output script picked up front, with no wait
(recovery)

Below is a sketch of a replacement for the two opcodes. Ignore my
inconsistency on VERIFY/non-VERIFY behavior, seeing if people agree with
this general direction:

`OP_TRIGGER_FORWARD`: Takes exactly three arguments:
1) output index to match against (provided at spend time normally)
2) target-outputs-hash: 32 byte hash to be forwarded to output given at (1)
(provided at spend time normally)
3) spend-delay: value to be forwarded to output given at (1)

Fails script immediately if there aren't enough inputs or they're the wrong
format.

These last two arguments are "forwarded" to output at index declared in
first argument, resulting in:

`EXPR_WITHDRAW: <spend-delay> OP_CHECKSEQUENCEVERIFY OP_DROP
<target-outputs-hash> OP_FORWARD_OUTPUTS`

As the derived tapscript, embedded in a output scriptpubkey of the form:
`tr(NUMS,{...,EXPR_WITHDRAW})`, meaning we literally take the control block
from the spending input, swap the inner pubkey for `NUMS`, use
`EXPR_WITHDRAW` as the tapleaf, reconstruct the merkle root. If the output
scriptpubkey doesnt match, fail.

This TLUV-ish script/inner pubkey replacement is meant to allow arbitrary
other conditions, which is where the "recovery" path comes in for typical
usage.

If output at the target output index doesn't match the constructed script,
the evaluation fails.

`OP_FORWARD_DESTINATION`: Takes exactly two arguments:
1) `dest-vout-idx`: index of output that contains the so-called "recovery"
path
2) <recovery sPK tagged hash (32 bytes)>: the hash of the script destinatio=
n

Fails immediately if the reconstructed output script doesn't match.

`OP_FORWARD_OUTPUTS` takes exactly one argument:
1) target-outputs-hash: commits to all outputs' scripts and values

Fails immediately if transaction's outputs(including value) hash doesn't
match.

**Typical usage**:
```
DEPOSITING TO VAULT SCRIPT:

EXPR_RECOVERY:   <recovery> <auth> <stuff> <recovery sPK tagged hash (32
bytes)> OP_FORWARD_DESTINATION
EXPR_TRIGGER:     <trigger> <auth> <stuff> <spend-delay> OP_TRIGGER_FORWARD

tr(KEY, {EXPR_RECOVERY, EXPR_TRIGGER})
```

```
EXPR_WITHDRAW: <spend-delay> OP_CHECKSEQUENCEVERIFY OP_DROP
<target-outputs-hash> OP_FORWARD_OUTPUTS
```

```
TRIGGERING WITHDRAWAL TIMER SCRIPT:

tr(NUMS, {EXPR_RECOVERY,EXPR_WITHDRAW}) <--- note EXPR_RECOVERY is forced
by the OP_TRIGGER_FORWARD TLUV action
```

Could save 2 WU having OP_FORWARD_OUTPUTS take the <spend-delay> directly
as an argument, or keep it more general as I did.

Would love to know what you and others think about this direction. I
apologies for any misunderstandings I have about the current OP_VAULT BIP!

Cheers,
Greg

On Mon, Feb 13, 2023 at 4:09=E2=80=AFPM James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Since the last related correspondence on this list [0], a number of
> improvements have been made to the OP_VAULT draft [1]:
>
> * There is no longer a hard dependence on package relay/ephemeral
>   anchors for fee management. When using "authorized recovery," all
>   vault-related transactions can be bundled with unrelated inputs and
>   outputs, facilitating fee management that is self contained to the
>   transaction. Consequently, the contents of this proposal are in theory
>   usable today.
>
> * Specific output locations are no longer hardcoded in any of the
>   transaction validation algorithms. This means that the proposal is now
>   compatible with future changes like SIGHASH_GROUP, and
>   transaction shapes for vault operations are more flexible.
>
> ---
>
> I've written a BIP that fully describes the proposal here:
>
>
> https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.med=
iawiki
>
> The corresponding PR is here:
>
>   https://github.com/bitcoin/bips/pull/1421
>
> My next steps will be to try for a merge to the inquisition repo.
>
> Thanks to everyone who has participated so far, but especially to AJ and
> Greg for all the advice.
>
> James
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/0213=
18.html
> [1]: https://github.com/bitcoin/bitcoin/pull/26857
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000bd2de805f5d80c26
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello James,</div><div><br></div>First off, thank you=
 for crafting an interesting idea like this that is aimed at solving a seri=
ous problem. I see a lot of excitement about the use cases, and I think it&=
#39;s worth=C2=A0iterating on.<br><br>Attempting to keep the idealized func=
tionality constant, I&#39;d like to explore a design detour.=C2=A0I&#39;m a=
ttempting to decouple the 3 functionalities of `OP_VAULT` and `OP_UNVAULT` =
into their constituent functions with names I just made up.<div><br></div><=
div>The goals of this e-mail:</div><div><br></div><div>1) Removing variable=
 number of arguments based on values of arguments for the opcodes.</div><di=
v>To me as a spec reader, I find it very difficult to parse what&#39;s prec=
isely happening when. I think the only/last opcode to support this behavior=
 was OP_CHECKMULTISIG(could be wrong), and now I know another reason why OP=
_CSA construct is nicer going forward with taproot.</div><div><br></div><di=
v>2) Remove the recursive evaluation functionality used for authentication,=
 without reducing the efficacy of the targeted solution. Recursive evaluati=
on has a fraught history in Bitcoin script, makes composing functionality w=
ith tooling likely more difficult, and has a lot of templated behavior. If =
we can rely on regular old tapscript to get us where we need to go, I&#39;d=
 prefer that.<br><br>3) Increase legibility of the spec. There&#39;s a ton =
going on, breaking things up and naming them based on the method rather tha=
n the goal may help here.</div><div><br></div><div>4) Not (greatly) increas=
e the expressiveness of the proposal. It&#39;s a targeted proposal, and I&#=
39;d like to respect that. These covenant opcodes are intended to be drop-i=
n replacements for the OP_(UN)VAULT opcodes.</div><div><br>To recap, there =
are three things happen in idealized OP_VAULT scenario:<br>1) Money comes o=
ut, then has to wait (trigger transaction)<br>2) Money waits long enough, t=
hen withdrawals to dynamic set of outputs that are declared at trigger time=
 (withdrawal transaction)<br>3) Money to single specified output script pic=
ked up front, with no wait (recovery)<br><br>Below is a sketch of a replace=
ment for the two opcodes. Ignore my inconsistency on VERIFY/non-VERIFY beha=
vior, seeing if people agree with this general direction:<br><br>`OP_TRIGGE=
R_FORWARD`: Takes exactly three arguments:<br>1) output index to match agai=
nst (provided at spend time normally)<br>2) target-outputs-hash: 32 byte ha=
sh to be forwarded to output given at (1) (provided at spend time normally)=
<br>3) spend-delay: value to be forwarded to output given at (1)<br><br>Fai=
ls script immediately if there aren&#39;t enough inputs or they&#39;re the =
wrong format.<br><br>These last two arguments are &quot;forwarded&quot; to =
output at index declared in first argument, resulting in:<br><br>`EXPR_WITH=
DRAW: &lt;spend-delay&gt; OP_CHECKSEQUENCEVERIFY OP_DROP &lt;target-outputs=
-hash&gt; OP_FORWARD_OUTPUTS`<br><br>As the derived tapscript, embedded in =
a output scriptpubkey of the form:<br>`tr(NUMS,{...,EXPR_WITHDRAW})`, meani=
ng we literally take the control block from the spending input, swap the in=
ner pubkey for `NUMS`, use `EXPR_WITHDRAW` as the tapleaf, reconstruct the =
merkle root. If the output scriptpubkey doesnt match, fail.<br><br>This TLU=
V-ish script/inner pubkey replacement is meant to allow arbitrary other con=
ditions, which is where the &quot;recovery&quot; path comes in for typical =
usage.</div><div><br></div><div>If output at the target output index doesn&=
#39;t match the constructed script, the evaluation fails.<br><br>`OP_FORWAR=
D_DESTINATION`: Takes exactly two arguments:<br>1) `dest-vout-idx`: index o=
f output that contains the so-called &quot;recovery&quot; path<br>2) &lt;re=
covery sPK tagged hash (32 bytes)&gt;: the hash of the script destination<b=
r><br>Fails immediately if the reconstructed output script doesn&#39;t matc=
h.<br><br>`OP_FORWARD_OUTPUTS` takes exactly one argument:<br>1) target-out=
puts-hash: commits to all outputs&#39; scripts and values</div><div><br></d=
iv><div>Fails immediately if transaction&#39;s outputs(including value) has=
h doesn&#39;t match.<br><br>**Typical usage**:<br>```<br>DEPOSITING TO VAUL=
T SCRIPT:<br><br>EXPR_RECOVERY: =C2=A0 &lt;recovery&gt; &lt;auth&gt; &lt;st=
uff&gt; &lt;recovery sPK tagged hash (32 bytes)&gt; OP_FORWARD_DESTINATION<=
br>EXPR_TRIGGER: =C2=A0 =C2=A0 &lt;trigger&gt; &lt;auth&gt; &lt;stuff&gt; &=
lt;spend-delay&gt; OP_TRIGGER_FORWARD<br><br>tr(KEY, {EXPR_RECOVERY, EXPR_T=
RIGGER})<br>```<br><br>```<br>EXPR_WITHDRAW: &lt;spend-delay&gt; OP_CHECKSE=
QUENCEVERIFY OP_DROP &lt;target-outputs-hash&gt; OP_FORWARD_OUTPUTS<br></di=
v><div>```<br><br>```<br>TRIGGERING WITHDRAWAL TIMER SCRIPT:<br><br>tr(NUMS=
, {EXPR_RECOVERY,EXPR_WITHDRAW}) &lt;--- note EXPR_RECOVERY is forced by th=
e OP_TRIGGER_FORWARD TLUV action<br>```<br><br></div><div>Could save 2 WU h=
aving OP_FORWARD_OUTPUTS take the &lt;spend-delay&gt; directly as an argume=
nt, or keep it more general as I did.</div><div><br></div><div>Would love t=
o know what you and others think about this direction. I apologies for any =
misunderstandings I have about the current OP_VAULT BIP!</div><div><br></di=
v><div>Cheers,</div><div>Greg</div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 13, 2023 at 4:09=E2=80=AFPM =
James O&#39;Beirne via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<b=
r></div><blockquote 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">=
Since the last related correspondence on this list [0], a number of<br>impr=
ovements have been made to the OP_VAULT draft [1]:<br><br>* There is no lon=
ger a hard dependence on package relay/ephemeral<br>=C2=A0 anchors for fee =
management. When using &quot;authorized recovery,&quot; all<br>=C2=A0 vault=
-related transactions can be bundled with unrelated inputs and<br>=C2=A0 ou=
tputs, facilitating fee management that is self contained to the<br>=C2=A0 =
transaction. Consequently, the contents of this proposal are in theory<br>=
=C2=A0 usable today.<br><br>* Specific output locations are no longer hardc=
oded in any of the<br>=C2=A0 transaction validation algorithms. This means =
that the proposal is now<br>=C2=A0 compatible with future changes like SIGH=
ASH_GROUP, and<br>=C2=A0 transaction shapes for vault operations are more f=
lexible.<br><br>---<br><br>I&#39;ve written a BIP that fully describes the =
proposal here:<br><br>=C2=A0 <a href=3D"https://github.com/jamesob/bips/blo=
b/jamesob-23-02-opvault/bip-vaults.mediawiki" target=3D"_blank">https://git=
hub.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki</a><br=
><br>The corresponding PR is here:<br><br>=C2=A0 <a href=3D"https://github.=
com/bitcoin/bips/pull/1421" target=3D"_blank">https://github.com/bitcoin/bi=
ps/pull/1421</a><br><br>My next steps will be to try for a merge to the inq=
uisition repo.<div><br>Thanks to everyone who has participated so far, but =
especially to AJ and<br>Greg for all the advice.<div><br>James<br><br>[0]: =
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-Jan=
uary/021318.html" target=3D"_blank">https://lists.linuxfoundation.org/piper=
mail/bitcoin-dev/2023-January/021318.html</a><br>[1]: <a href=3D"https://gi=
thub.com/bitcoin/bitcoin/pull/26857" target=3D"_blank">https://github.com/b=
itcoin/bitcoin/pull/26857</a><br></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000bd2de805f5d80c26--