Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 98BC7C002D for ; Tue, 10 Jan 2023 20:23:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6D40340436 for ; Tue, 10 Jan 2023 20:23:07 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6D40340436 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=WAhSrELz X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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 xSS5bGASMosE for ; Tue, 10 Jan 2023 20:23:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 406A340002 Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by smtp2.osuosl.org (Postfix) with ESMTPS id 406A340002 for ; Tue, 10 Jan 2023 20:23:05 +0000 (UTC) Received: by mail-oi1-x232.google.com with SMTP id r205so11080521oib.9 for ; Tue, 10 Jan 2023 12:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uT5KIwAwUwo99Y1iDRg97XTXTDFxWNwnSP6zhd8EVhg=; b=WAhSrELzjc2g0pYxVz4m0NTWIkVDGvxymEINAct73Bb7z2u+xqUiDUI1JZp+YiH/c3 HF7Y0QoE1z4PF9k08nPLrvRDYJ8KrKv4qRnb9MvI8ikQvZIqp09C8NjLdzoqw1o8xQfY 3B996ZbTvRhP6HLiZGjwXc6K53SIJhqBwJoUOLZIzZNbnEzfHSETTvpcHfmesxqkj2/2 m89lQ6k4UxIJXgd3vnWVs36ROiAeHjeLLwdr71pIem73MFVCOOMij3d+x8tnpQkf1tfJ VhEgOnkaV0/Hrq8+8uwovaZ5fId/mbOjWpTCW1S28JMYQitsw0x16T0aRe6LZEmFcjxt NzdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=uT5KIwAwUwo99Y1iDRg97XTXTDFxWNwnSP6zhd8EVhg=; b=BQVK+yBzLqlVUE2uy5D7RhD2TQ0PI2DHSavv6TAot6DzA20a06kwuqYMC77fWgq1Yh WdhbQzPt3evsbBHGpGsK98t/wbHHCE1DaF0qxmvHHOtyYtP7ejBY0OhvHRgGaRdYAR0+ fatMBs3lR2B8htkh1UllAkiYvLCp6ST4jRZdxcpf8O71xk7kQjEG+Zti+USgTJ73I/3T Gyf3gMHAHH1HJT36oHjGyOgjTz/fhOR9eCsw/K7mSTDsVa07GfQp1d7I79Q5ZKW2/L1N RF86+z7LHfCSv96gNFjOWzPxtMG+cs02G/+WEo+cJpmOjUPgUk+UKfhgYlm1I0PymIcB XWAA== X-Gm-Message-State: AFqh2kpdDg7hNbHWqqIKPJRaL+hld2k2QkGC9veHrC6W5amMD6xd4nQV aYbCRiDLJu+X7EoYCdasHYt+0aLEo4TRaML4IUdbe34xZGw= X-Google-Smtp-Source: AMrXdXsdNIf1IQDJnOB020JeHdY5DxV48SupkxwtXJQlLnzjrd7eznbCYW1CIkWL/TpKvaY+A4wXmRf2m1+vKEsm0Cs= X-Received: by 2002:a05:6808:20a:b0:35a:774e:d352 with SMTP id l10-20020a056808020a00b0035a774ed352mr4226437oie.193.1673382184020; Tue, 10 Jan 2023 12:23:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "James O'Beirne" Date: Tue, 10 Jan 2023 15:22:54 -0500 Message-ID: To: Anthony Towns Content-Type: multipart/alternative; boundary="000000000000a6edeb05f1eea6f6" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] OP_VAULT: a new vault proposal 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: Tue, 10 Jan 2023 20:23:07 -0000 --000000000000a6edeb05f1eea6f6 Content-Type: text/plain; charset="UTF-8" Thanks for the thoughtful reply AJ. > I don't think that makes sense? With a general scheme, you'd only be > bloating the witness data (perhaps including the witness script) not > the scriptPubKey? Sorry, sloppy language on my part. To be charitable, I'm talking about the "figurative sPK," which of course these days lives in the witness for script-path-ish spends. Maybe the witness discount means that "complicated" scripts aren't as big a deal, depending on the actual difference in raw script size. > I think it might be better to use a pay-to-contract construction for > the recovery path, rather than an empty witness. So I guess the one advantage that what you're proposing has over just using a recovery-path key signature is that it's all derivable from your cold privkey; you don't have to worry about accidentally losing the recovery-path key. Of course you're still vulnerable to spurious sweeps if the sha256(secret) value gets found out, which presumably you'd want in an accessible cache to avoid touching the cold secret every time you want to sweep. What do you think about the idea of making the recovery-path authorization behavior variable on a single byte flag preceding the 32 byte data push, as I mentioned in another post? I think it may make sense to leave this option open to end-users (and also allow for some upgradeability). > I think a generic OP_UNVAULT can be used to simulate OP_CTV: replace > " OP_CTV" with "<000..0> 0 OP_UNVAULT". Yup, that's an inefficient way of emulating CTV. If people want CTV, we should just look at activating CTV. Greg Sanders has a thing about "jetting" CTV into this proposal (I think) so that the code-paths are shared, but I haven't figured out how that would work. They really don't share that much code AFAICT. > The paper seems to put "OP_UNVAULT" first, but the code seems to > expect it to come last, not sure what's up with that inconsistency. Again some sloppy notation on my part. What I sort of meant in the paper was a kind of functional notation `OP_VAULT(param1, param2, ...)`. Let's chalk that up to my inexperience actually working on script stuff. > I think there's maybe a cleverer way of batching / generalising > checking that input/output amounts match. > > [...] > > * set C = the sum of each output that has a vault tag with > #recovery=X This would also need to take into account that the s are compatible, but your point is well taken. > I think one meaningful difference between these two approaches is that > the current proposal means unvaulting locks up the entire utxo for the > delay period, rather than just the amount you're trying to unvault. This is a really good point and I think is one that's important to incorporate with a change to the existing proposal. A simple fix for facilitating the use of a "partial revault" while the OP_UNVAULT UTXO is outstanding would be to allow for an optional third output that is a redeposit back to the identical OP_VAULT sPK that is being spent by the OP_UNVAULT transaction, then the script interpreter would just ensure that the nValue of those two outputs sums to the sum of the input nValues. I can see what you're saying about having more generic "group amounts by compatible vault params, and then compare to similarly grouped outputs," but I'm just wondering if there are other uses that enables besides the partial-revault thing I mentioned above. If not, I'd probably rather just stick with something simple like having the third optional re-vault output. > Changing the unvault construction to have an optional OP_VAULT output > would remedy that, I think. Oh - okay, this is what you're saying. Right! Is that a sufficient change, or are there other benefits that the more complicated clever-I/O-vault-grouping would enable that you have in mind? > What would it look like to just hide all this under taproot? > > [...] > > It also needs some way of constructing "unvault[X]", which could be a > TLUV-like construction. > > That all seems possible to me; though certainly needs more work/thought > than just having dedicated opcodes and stuffing the data directly in > the sPK. I think this is a very important comparison to do, but I'm eager to see code for things like this. There have been a lot of handwavey proposals lately without tangible code artifacts. I'm eager to see what these alternatives look like in practice - i.e. in functional tests. Thanks again for the great mail. James --000000000000a6edeb05f1eea6f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the thoughtfu= l reply AJ.

> I don't think that makes sense? With a general scheme, you'd= only be
> bloating the witness data (perhaps including the witness s= cript) not
> the scriptPubKey?

Sorry, sloppy language o= n my part. To be charitable, I'm talking about
the "figurative = sPK," which of course these days lives in the witness
for script-pa= th-ish spends. Maybe the witness discount means that
"complicated&q= uot; scripts aren't as big a deal, depending on the actual
differenc= e in raw script size.=


> I think it might be better to use a pay-to-contract constr= uction for
> the recovery path, rather than an empty witness.

= So I guess the one advantage that what you're proposing has over= just
using a recovery-path key signature is that it's all derivable= from your
cold privkey; you don't have to worry about accidentally = losing the
recovery-path key.

Of course you're still vulnerab= le to spurious sweeps if the
sha256(secret) value gets found out, which = presumably you'd want in an
accessible cache to avoid touching the c= old secret every time you want
to sweep.

What do you think about = the idea of making the recovery-path
authorization behavior variable on = a single byte flag preceding the 32
byte data push, as I mentioned in an= other post? I think it may make
sense to leave this option open to end-u= sers (and also allow for some
upgradeability).


> I think a generic OP_UNVAULT c= an be used to simulate OP_CTV: replace
> "<h> OP_CTV"= with "<000..0> 0 <h> OP_UNVAULT".

Yup,= that's an inefficient way of emulating CTV. If people want CTV, we
= should just look at activating CTV. Greg Sanders has a thing about
"= ;jetting" CTV into this proposal (I think) so that the code-paths are<= br>shared, but I haven't figured out how that would work. They really
don't share that much code AFAICT.


> The paper seems to put "OP_UNVAULT" first= , but the code seems to
> expect it to come last, not sure what's= up with that inconsistency.

Again some sloppy notation on my= part. What I sort of meant in the paper
was a kind of functional notati= on `OP_VAULT(param1, param2, ...)`. Let's
chalk that up to my inexpe= rience actually working on script stuff.


> I think there's maybe a cleverer wa= y of batching / generalising
> checking that input/output amounts mat= ch.
>
> [...]
>
> =C2=A0* set C =3D the sum of= each output that has a vault tag with
> =C2=A0 =C2=A0#recovery=3DX
This would also need to take into account that the <spend-d= elay>s are
compatible, but your point is well taken.


> I think one meaningfu= l difference between these two approaches is that
> the current propo= sal means unvaulting locks up the entire utxo for the
> delay period,= rather than just the amount you're trying to unvault.

Th= is is a really good point and I think is one that's important to
inc= orporate with a change to the existing proposal.

A simple fix for fa= cilitating the use of a "partial revault" while the
OP_UNVAULT= UTXO is outstanding would be to allow for an optional
third output that= is a redeposit back to the identical OP_VAULT sPK that
is being spent b= y the OP_UNVAULT transaction, then the script
interpreter would just ens= ure that the nValue of those two outputs sums
to the sum of the input nV= alues.

I can see what you're saying about having more generic &q= uot;group amounts by
compatible vault params, and then compare to simila= rly grouped outputs,"
but I'm just wondering if there are other= uses that enables besides the
partial-revault thing I mentioned above. = If not, I'd probably rather just stick
with something simple like ha= ving the third optional re-vault output.


> Changing the unvault construction to ha= ve an optional OP_VAULT output
> would remedy that, I think.

<= /span>Oh - okay, this is what you're saying. Right!

Is that a su= fficient change, or are there other benefits that the more
complicated c= lever-I/O-vault-grouping would enable that you have in
mind?


> What would it l= ook like to just hide all this under taproot?
>
> [...]<= span class=3D"gmail-im" style=3D"color:rgb(80,0,80)">
>
> It al= so needs some way of constructing "unvault[X]", which could be a<= br>> TLUV-like construction.
>
> That all seems possible to = me; though certainly needs more work/thought
> than just having dedic= ated opcodes and stuffing the data directly in
> the sPK.

I think this is a very important comparison to do, but I'm eager to = see
code for things like this. There have been a lot of handwavey propos= als
lately without tangible code artifacts. I'm eager to see what th= ese
alternatives look like in practice - i.e. in functional tests.


Thanks again for the great mail.
James
--000000000000a6edeb05f1eea6f6--