Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2FAA2C0032 for ; 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 ; 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 ; 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 ; Wed, 1 Mar 2023 15:06:01 +0000 (UTC) Received: by mail-ed1-x531.google.com with SMTP id cq23so55173464edb.1 for ; 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: In-Reply-To: From: Greg Sanders Date: Wed, 1 Mar 2023 10:05:47 -0500 Message-ID: To: "James O'Beirne" , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: OP_CHECKSEQUENCEVERIFY OP_DROP 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) : 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: OP_FORWARD_DESTINATION EXPR_TRIGGER: OP_TRIGGER_FORWARD tr(KEY, {EXPR_RECOVERY, EXPR_TRIGGER}) ``` ``` EXPR_WITHDRAW: OP_CHECKSEQUENCEVERIFY OP_DROP 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 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
Hello James,

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.

Attempting to keep the idealized func= tionality constant, I'd like to explore a design detour.=C2=A0I'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>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 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.

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'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 tha= n the goal may help here.

4) Not (greatly) increas= e the expressiveness of the proposal. It'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.

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

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:

`OP_TRIGGE= R_FORWARD`: Takes exactly three arguments:
1) output index to match agai= nst (provided at spend time normally)
2) target-outputs-hash: 32 byte ha= sh 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)

Fai= ls 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_WITH= DRAW: <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})`, 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.

This TLU= V-ish script/inner pubkey replacement is meant to allow arbitrary other con= ditions, which is where the "recovery" path comes in for typical = usage.

If output at the target output index doesn&= #39;t match the constructed script, the evaluation fails.

`OP_FORWAR= D_DESTINATION`: Takes exactly two arguments:
1) `dest-vout-idx`: index o= f output that contains the so-called "recovery" path
2) <re= covery sPK tagged hash (32 bytes)>: the hash of the script destination
Fails immediately if the reconstructed output script doesn't matc= h.

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

Fails immediately if transaction's outputs(including value) has= h doesn't match.

**Typical usage**:
```
DEPOSITING TO VAUL= T SCRIPT:

EXPR_RECOVERY: =C2=A0 <recovery> <auth> <st= uff> <recovery sPK tagged hash (32 bytes)> OP_FORWARD_DESTINATION<= br>EXPR_TRIGGER: =C2=A0 =C2=A0 <trigger> <auth> <stuff> &= lt;spend-delay> OP_TRIGGER_FORWARD

tr(KEY, {EXPR_RECOVERY, EXPR_T= RIGGER})
```

```
EXPR_WITHDRAW: <spend-delay> OP_CHECKSE= QUENCEVERIFY OP_DROP <target-outputs-hash> OP_FORWARD_OUTPUTS
```

```
TRIGGERING WITHDRAWAL TIMER SCRIPT:

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

Could save 2 WU h= aving OP_FORWARD_OUTPUTS take the <spend-delay> directly as an argume= nt, or keep it more general as I did.

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!

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
impr= ovements have been made to the OP_VAULT draft [1]:

* There is no lon= ger a hard dependence on package relay/ephemeral
=C2=A0 anchors for fee = management. When using "authorized recovery," all
=C2=A0 vault= -related transactions can be bundled with unrelated inputs and
=C2=A0 ou= tputs, facilitating fee management that is self contained to the
=C2=A0 = transaction. Consequently, the contents of this proposal are in theory
= =C2=A0 usable today.

* Specific output locations are no longer hardc= oded in any of the
=C2=A0 transaction validation algorithms. This means = that the proposal is now
=C2=A0 compatible with future changes like SIGH= ASH_GROUP, and
=C2=A0 transaction shapes for vault operations are more f= lexible.

---

I've written a BIP that fully describes the = proposal here:

=C2=A0 https://git= hub.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki
The corresponding PR is here:

=C2=A0 https://github.com/bitcoin/bi= ps/pull/1421

My next steps will be to try for a merge to the inq= uisition repo.

Thanks to everyone who has participated so far, but = especially to AJ and
Greg for all the advice.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000bd2de805f5d80c26--