path: root/47/52fd4cb5e9b228e6c6bbe993741be1a7ab4e35

Return-Path: <james.obeirne@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 63199C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 18 Jan 2023 23:38:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 32A7141908
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 18 Jan 2023 23:38:04 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 32A7141908
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=GCQTQTLr
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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id SHyX-SskgSIy
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 18 Jan 2023 23:38:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AB8A941903
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com
 [IPv6:2607:f8b0:4864:20::22c])
 by smtp4.osuosl.org (Postfix) with ESMTPS id AB8A941903
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 18 Jan 2023 23:38:01 +0000 (UTC)
Received: by mail-oi1-x22c.google.com with SMTP id p133so360178oig.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 18 Jan 2023 15:38: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=eWx0SGzKxJ0KEF7/QZXzy8b1e/dzeHRdpHQIP4aK9nI=;
 b=GCQTQTLrnRjX46UVd1IAvgy61eA+Si7jxycdX7IOl9NZnDksGNUkPH4PpxMUUBJjrL
 tvb6rC1RaRYZk148tH/aWj7ULQTFGX7EVRHpOybO8aClXaXfhXaKHFVkW49O2MnPukHN
 bk5n+4HgBx1KGOkDt6Iq03xXbg8NNW/psL1ckgz/DMVEeKrMXzh6HjvBgCKXHir2Pmfi
 bXqb3uqkv8wOhGdOdmjwdXvH3OLFeU/jSdPYYewskAIDt0p+F8e2g9Ng/ejnddm05Qvf
 pz9vh95pabc4GOwaCJtshV+rcPx+5PP6Yo7kSazkr8U781xZ9NBkvDNL6tScjuGnRqdq
 ip1w==
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=eWx0SGzKxJ0KEF7/QZXzy8b1e/dzeHRdpHQIP4aK9nI=;
 b=o7xZoZ+Br0GyO8zif6XHdwDZQvIvLMFJoSr+BSATBE/8aT+vCZRSEKAHhwYmK3gJuD
 neRnqa9S5hbyepMKslyZ1lajVJBsFOHAaB6hPmHvXpmQFyVFbDVOnsgUlGx+GZdBs7bv
 sAbohxPS9wg4ANrvM85E19f4OYsmgTuVJt2GPPNA+/GbsEdd9KmjColuhjSWwDfJRUMq
 OIvOhJf8TGcoeTUuB0L4a2AYWNWjUhZ5eopKlJ4S+Tmr0SUf5vNiVlwOmcTR+5dvA2sn
 Jf1FQz/rR67tUBnxV8MndF64XQgFZCjhYWBWpbjMh1YGykuusm9tP0UOj/ornrc8C3Lt
 PsAw==
X-Gm-Message-State: AFqh2kpbcvNcrWRFTArVgsFIbgTMYkKJv5cCwR8FKozhBYYmN8DEo3qR
 azAvu4wNVE92zoPq1LqB1+xVfskEPhwlA/EV1Vs=
X-Google-Smtp-Source: AMrXdXt+P0DmIr9nqj4n8/FLdCE51jEtHU58doqPNUHqTPBz+xK9aRNMjcWQAH5j2ehAbDT3ZVk+7QiLxpcCQS7xXfA=
X-Received: by 2002:aca:b708:0:b0:35a:774e:d352 with SMTP id
 h8-20020acab708000000b0035a774ed352mr525294oif.193.1674085080366; Wed, 18 Jan
 2023 15:38:00 -0800 (PST)
MIME-Version: 1.0
References: <afde051e-4e63-368c-3251-70f829a51c4e@achow101.com>
 <Y8ZSXrxfR8HrB8zD@erisian.com.au>
 <CAGpPWDbLC-om+SR5boRv8U0RptqRUMYJhYvnLbpvm3AKOuX4Fg@mail.gmail.com>
In-Reply-To: <CAGpPWDbLC-om+SR5boRv8U0RptqRUMYJhYvnLbpvm3AKOuX4Fg@mail.gmail.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Wed, 18 Jan 2023 18:37:51 -0500
Message-ID: <CAPfvXf+GaJ-fO9TJVpSaKKhQU79p7krzFQg7+92PA5wHS3ps0Q@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008a02db05f2924ef4"
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: Wed, 18 Jan 2023 23:38:04 -0000

--0000000000008a02db05f2924ef4
Content-Type: text/plain; charset="UTF-8"

> I don't see in the write up how a node verifies that the destination
> of a spend using an OP_VAULT output uses an appropriate OP_UNVAULT
> script.

It's probably quicker for you to just read through the
implementation that I reference in the last section of the paper.

https://github.com/bitcoin/bitcoin/blob/fdfd5e93f96856fbb41243441177a40ebbac6085/src/script/interpreter.cpp#L1419-L1456

> It would usually be prudent to store this recovery address with every
> key to the vault, ...

I'm not sure I really follow here. Worth noting now that in OP_VAULT the
recovery path can be optionally gated by an arbitrary scriptPubKey.

> This is rather limiting isn't it? Losing the key required to sign
> loses your recovery option.

This functionality is optional in OP_VAULT as of today. You can specify
OP_TRUE (or maybe I should allow empty?) in the <recovery-params> to
disable any signing necessary for recovery.

> Wouldn't it be reasonably possible to allow recovery outputs with any
> recovery address to be batched, and the amount sums sent to each to be
> added up and verified?

I think the space savings from this is pretty negligible, since you're
just saving on the transaction overhead, and it makes the implementation
decently more complicated. One benefit might be sharing a common
fee-management output (e.g. ephemeral anchor) across the separate vaults
being recovered.

> If someday wallet vaults are the standard wallet construct, people
> might not even want to have a non-vault wallet just for use in
> unvaulting.

If you truly lacked any non-vaulted UTXOs and couldn't get any at a
reasonable price (?), I can imagine there might be a mechanism where you
include a payout output to some third party in a drafted unvault trigger
transaction, and they provide a spend of the ephemeral output.

Though you do raise a good point that this construction as written may
not be compatible with SIGHASH_GROUP... I'd have to think about that
one.

> Hmm, it seems inaccurate to say that step is "skipped". While there
> isn't a warm wallet step, its replaced with an OP_UNVAULT script step.

It is "skipped" in the sense that your bitcoin can't be stolen by having
to pass through some intermediate wallet during an authorized withdrawal
to a given target, in the way that they could if you had to prespecify
an unvault target when creating the vault.


---


> My proposal for efficient wallet vaults was designed to meet all of
> those criteria, and allows batching as well.

Probably a discussion of your proposal merits a different thread, but
some thoughts that occur:


> [from the README]
>
> OP_BEFOREBLOCKVERIFY - Verifies that the block the transaction is
> within has a block height below a particular number. This allows a
> spend-path to expire.

I think this breaks fundamental reorgability of transactions. I think
some of the other opcodes, e.g the one that limits fee contribution on
the basis of historical feerate, are going to be similarly
controversial.

> This is done by using a static intermediate address that has no values
> that are unique to the particular wallet vault address.

Does mean either that (i) this proposal doesn't have dynamic unvaulting
targets or, (ii) if you do, in order to be batch unvaulted, vaulted
coins need to first be spent into this intermediate output?

It sounds like (ii) is the case, given that your unvault target
specification lives in (I think?) the witness for the spend creating the
intermediate output.

If the intermediate address doesn't have any values which are unique to
a particular vault, how do you authorize recoveries from it?

---

Personally I think if you'd like to pursue your proposal, it'd be
valuable to see a full implementation. Might also make it easier to
assess the viability of the proposal.

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

<div dir=3D"ltr"><div dir=3D"ltr">&gt; I don&#39;t see in the write up how =
a node verifies that the destination<br>&gt; of a spend using an OP_VAULT o=
utput uses an appropriate OP_UNVAULT<br>&gt; script.<br><br>It&#39;s probab=
ly quicker for you to just read through the<br>implementation that I refere=
nce in the last section of the paper.<br><br><a href=3D"https://github.com/=
bitcoin/bitcoin/blob/fdfd5e93f96856fbb41243441177a40ebbac6085/src/script/in=
terpreter.cpp#L1419-L1456">https://github.com/bitcoin/bitcoin/blob/fdfd5e93=
f96856fbb41243441177a40ebbac6085/src/script/interpreter.cpp#L1419-L1456</a>=
<br><br>&gt; It would usually be prudent to store this recovery address wit=
h every<br>&gt; key to the vault, ...<br><br>I&#39;m not sure I really foll=
ow here. Worth noting now that in OP_VAULT the<br>recovery path can be opti=
onally gated by an arbitrary scriptPubKey.<br><br>&gt; This is rather limit=
ing isn&#39;t it? Losing the key required to sign<br>&gt; loses your recove=
ry option. <br><br>This functionality is optional in OP_VAULT as of today. =
You can specify<br>OP_TRUE (or maybe I should allow empty?) in the &lt;reco=
very-params&gt; to<br>disable any signing necessary for recovery.<br><br>&g=
t; Wouldn&#39;t it be reasonably possible to allow recovery outputs with an=
y<br>&gt; recovery address to be batched, and the amount sums sent to each =
to be<br>&gt; added up and verified?<br><br>I think the space savings from =
this is pretty negligible, since you&#39;re<br>just saving on the transacti=
on overhead, and it makes the implementation<br>decently more complicated. =
One benefit might be sharing a common<br>fee-management output (e.g. epheme=
ral anchor) across the separate vaults<br>being recovered.<br><br>&gt; If s=
omeday wallet vaults are the standard wallet construct, people<br>&gt; migh=
t not even want to have a non-vault wallet just for use in<br>&gt; unvaulti=
ng. <br><br>If you truly lacked any non-vaulted UTXOs and couldn&#39;t get =
any at a<br>reasonable price (?), I can imagine there might be a mechanism =
where you<br>include a payout output to some third party in a drafted unvau=
lt trigger<br>transaction, and they provide a spend of the ephemeral output=
.<br><br>Though you do raise a good point that this construction as written=
 may<br>not be compatible with SIGHASH_GROUP... I&#39;d have to think about=
 that<br>one.<br><br>&gt; Hmm, it seems inaccurate to say that step is &quo=
t;skipped&quot;. While there<br>&gt; isn&#39;t a warm wallet step, its repl=
aced with an OP_UNVAULT script step. <br><br>It is &quot;skipped&quot; in t=
he sense that your bitcoin can&#39;t be stolen by having<br>to pass through=
 some intermediate wallet during an authorized withdrawal<br>to a given tar=
get, in the way that they could if you had to prespecify<br>an unvault targ=
et when creating the vault.<br><br><br>---<br><br><br>&gt; My proposal for =
efficient wallet vaults was designed to meet all of<br>&gt; those criteria,=
 and allows batching as well.<br><br>Probably a discussion of your proposal=
 merits a different thread, but<br>some thoughts that occur:<br><br><br>&gt=
; [from the README]<br>&gt; <br>&gt; OP_BEFOREBLOCKVERIFY - Verifies that t=
he block the transaction is<br>&gt; within has a block height below a parti=
cular number. This allows a<br>&gt; spend-path to expire.<br><br>I think th=
is breaks fundamental reorgability of transactions. I think<br>some of the =
other opcodes, e.g the one that limits fee contribution on<br>the basis of =
historical feerate, are going to be similarly<br>controversial.<br><br>&gt;=
 This is done by using a static intermediate address that has no values<br>=
&gt; that are unique to the particular wallet vault address. <br><br>Does m=
ean either that (i) this proposal doesn&#39;t have dynamic unvaulting<br>ta=
rgets or, (ii) if you do, in order to be batch unvaulted, vaulted<br>coins =
need to first be spent into this intermediate output?<br><br>It sounds like=
 (ii) is the case, given that your unvault target<br>specification lives in=
 (I think?) the witness for the spend creating the<br>intermediate output.<=
br><br>If the intermediate address doesn&#39;t have any values which are un=
ique to<br>a particular vault, how do you authorize recoveries from it? <br=
><br>---<br><br>Personally I think if you&#39;d like to pursue your proposa=
l, it&#39;d be<br>valuable to see a full implementation. Might also make it=
 easier to<br>assess the viability of the proposal.</div></div>

--0000000000008a02db05f2924ef4--