path: root/44/51078cf821f2d85b37695fb640bef52a79b177

Return-Path: <james.obeirne@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 98BC7C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 Jan 2023 20:23:05 +0000 (UTC)
Received: by mail-oi1-x232.google.com with SMTP id r205so11080521oib.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAPfvXfL65cneOabmxfOzTZq14xN4vXNaGboq_g15-frM14RqGA@mail.gmail.com>
 <Y71aQAxPXI+9C7rd@erisian.com.au>
In-Reply-To: <Y71aQAxPXI+9C7rd@erisian.com.au>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Tue, 10 Jan 2023 15:22:54 -0500
Message-ID: <CAPfvXfJSJwJ=0wYev7RDBzvgoi5D3HS8sjKqMxM9wcuh3FHvGw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="000000000000a6edeb05f1eea6f6"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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
> "<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
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 <spend-delay>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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Thanks for the thoughtfu=
l reply AJ.<span class=3D"gmail-im" style=3D"color:rgb(80,0,80)"><br><br><b=
r>&gt; I don&#39;t think that makes sense? With a general scheme, you&#39;d=
 only be<br>&gt; bloating the witness data (perhaps including the witness s=
cript) not<br>&gt; the scriptPubKey?<br><br></span>Sorry, sloppy language o=
n my part. To be charitable, I&#39;m talking about<br>the &quot;figurative =
sPK,&quot; which of course these days lives in the witness<br>for script-pa=
th-ish spends. Maybe the witness discount means that<br>&quot;complicated&q=
uot; scripts aren&#39;t as big a deal, depending on the actual<br>differenc=
e in raw script size.<span class=3D"gmail-im" style=3D"color:rgb(80,0,80)">=
<br><br><br>&gt; I think it might be better to use a pay-to-contract constr=
uction for<br>&gt; the recovery path, rather than an empty witness.<br><br>=
</span>So I guess the one advantage that what you&#39;re proposing has over=
 just<br>using a recovery-path key signature is that it&#39;s all derivable=
 from your<br>cold privkey; you don&#39;t have to worry about accidentally =
losing the<br>recovery-path key.<br><br>Of course you&#39;re still vulnerab=
le to spurious sweeps if the<br>sha256(secret) value gets found out, which =
presumably you&#39;d want in an<br>accessible cache to avoid touching the c=
old secret every time you want<br>to sweep.<br><br>What do you think about =
the idea of making the recovery-path<br>authorization behavior variable on =
a single byte flag preceding the 32<br>byte data push, as I mentioned in an=
other post? I think it may make<br>sense to leave this option open to end-u=
sers (and also allow for some<br>upgradeability).<span class=3D"gmail-im" s=
tyle=3D"color:rgb(80,0,80)"><br><br><br>&gt; I think a generic OP_UNVAULT c=
an be used to simulate OP_CTV: replace<br>&gt; &quot;&lt;h&gt; OP_CTV&quot;=
 with &quot;&lt;000..0&gt; 0 &lt;h&gt; OP_UNVAULT&quot;.<br><br></span>Yup,=
 that&#39;s an inefficient way of emulating CTV. If people want CTV, we<br>=
should just look at activating CTV. Greg Sanders has a thing about<br>&quot=
;jetting&quot; CTV into this proposal (I think) so that the code-paths are<=
br>shared, but I haven&#39;t figured out how that would work. They really</=
div><div dir=3D"ltr">don&#39;t share that much code AFAICT.</div><div dir=
=3D"ltr"><br></div><div dir=3D"ltr"><span class=3D"gmail-im" style=3D"color=
:rgb(80,0,80)"><br>&gt; The paper seems to put &quot;OP_UNVAULT&quot; first=
, but the code seems to<br>&gt; expect it to come last, not sure what&#39;s=
 up with that inconsistency.<br><br></span>Again some sloppy notation on my=
 part. What I sort of meant in the paper<br>was a kind of functional notati=
on `OP_VAULT(param1, param2, ...)`. Let&#39;s<br>chalk that up to my inexpe=
rience actually working on script stuff.<span class=3D"gmail-im" style=3D"c=
olor:rgb(80,0,80)"><br><br><br>&gt; I think there&#39;s maybe a cleverer wa=
y of batching / generalising<br>&gt; checking that input/output amounts mat=
ch.</span></div><div dir=3D"ltr">&gt;<br>&gt; [...]<span class=3D"gmail-im"=
 style=3D"color:rgb(80,0,80)"><br>&gt;<br>&gt; =C2=A0* set C =3D the sum of=
 each output that has a vault tag with<br>&gt; =C2=A0 =C2=A0#recovery=3DX<b=
r><br></span>This would also need to take into account that the &lt;spend-d=
elay&gt;s are<br>compatible, but your point is well taken.<span class=3D"gm=
ail-im" style=3D"color:rgb(80,0,80)"><br><br><br>&gt; I think one meaningfu=
l difference between these two approaches is that<br>&gt; the current propo=
sal means unvaulting locks up the entire utxo for the<br>&gt; delay period,=
 rather than just the amount you&#39;re trying to unvault.<br><br></span>Th=
is is a really good point and I think is one that&#39;s important to<br>inc=
orporate with a change to the existing proposal.<br><br>A simple fix for fa=
cilitating the use of a &quot;partial revault&quot; while the<br>OP_UNVAULT=
 UTXO is outstanding would be to allow for an optional<br>third output that=
 is a redeposit back to the identical OP_VAULT sPK that<br>is being spent b=
y the OP_UNVAULT transaction, then the script<br>interpreter would just ens=
ure that the nValue of those two outputs sums<br>to the sum of the input nV=
alues.<br><br>I can see what you&#39;re saying about having more generic &q=
uot;group amounts by<br>compatible vault params, and then compare to simila=
rly grouped outputs,&quot;<br>but I&#39;m just wondering if there are other=
 uses that enables besides the<br>partial-revault thing I mentioned above. =
If not, I&#39;d probably rather just stick<br>with something simple like ha=
ving the third optional re-vault output.<span class=3D"gmail-im" style=3D"c=
olor:rgb(80,0,80)"><br><br><br>&gt; Changing the unvault construction to ha=
ve an optional OP_VAULT output<br>&gt; would remedy that, I think.<br><br><=
/span>Oh - okay, this is what you&#39;re saying. Right!<br><br>Is that a su=
fficient change, or are there other benefits that the more<br>complicated c=
lever-I/O-vault-grouping would enable that you have in<br>mind?<span class=
=3D"gmail-im" style=3D"color:rgb(80,0,80)"><br><br><br>&gt; What would it l=
ook like to just hide all this under taproot?<br>&gt;<br></span>&gt; [...]<=
span class=3D"gmail-im" style=3D"color:rgb(80,0,80)"><br>&gt;<br>&gt; It al=
so needs some way of constructing &quot;unvault[X]&quot;, which could be a<=
br>&gt; TLUV-like construction.<br>&gt;<br>&gt; That all seems possible to =
me; though certainly needs more work/thought<br>&gt; than just having dedic=
ated opcodes and stuffing the data directly in<br>&gt; the sPK.<br><br></sp=
an>I think this is a very important comparison to do, but I&#39;m eager to =
see<br>code for things like this. There have been a lot of handwavey propos=
als<br>lately without tangible code artifacts. I&#39;m eager to see what th=
ese<br>alternatives look like in practice - i.e. in functional tests.<br><d=
iv><br></div><div><br></div><div>Thanks again for the great mail.</div><fon=
t color=3D"#888888"><div>James</div></font></div></div></div>

--000000000000a6edeb05f1eea6f6--