path: root/5d/696030be8eb7e641ba9ea15a02043d9dc18f0d

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 39CA2C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Jan 2023 22:49:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 10E9C408A6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Jan 2023 22:49:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 10E9C408A6
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=RKjWBEhh
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 NjWLP4hWHEtW
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Jan 2023 22:49:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0CE8D40895
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [IPv6:2a00:1450:4864:20::62a])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 0CE8D40895
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Jan 2023 22:49:47 +0000 (UTC)
Received: by mail-ej1-x62a.google.com with SMTP id rl14so6327796ejb.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 19 Jan 2023 14:49:47 -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=6yOnFRl5oMwZ0SYv56oKknmN5h3slKVIpUCyISbOycQ=;
 b=RKjWBEhhR3lW1Rxy64ZxCAVyQHp0WIJaL16SnF3rCvD9F1ZDAi/EJlHBEZzxD9KmBL
 /zRPxqJ+qR3HJGaNYEPAXwTGpp160QfQ/2PYANEnDE6DhbSgkVoCvLsVUtM19l8jVywj
 jefAWOCHEf1w3P5hLumIStnIb2ScwZp34tbY8eleO4lDiKS4DP/oghpFtzgTvV6U/rk4
 id+gQ8RMgfjCdFjTJJbbRtkEmIbS1+PLJuTUQB3q7OTkmpAh86q9Uyi5aQwY5Jj0oHE0
 5p2fxucEqRGqfa78Vx8ACJtLp8G375FskJcEhU6sbwjRzDRkjTmfxYVx2HwWzQ2F4Cdn
 S+vA==
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=6yOnFRl5oMwZ0SYv56oKknmN5h3slKVIpUCyISbOycQ=;
 b=Jq4YPdcyXsr3YiHd7qMrK1RdyxuQ+WdfEj2C8tmLNkIMHb6wHbXN9wzZNEAFCM8mm2
 ipGnMdpbi3U6w1WYII5NrS+xliKiQ6BS6NlnMwLDnX1dXUKenr8kcQFJGjmqTOW29yy1
 QnYwVdn4SHHn8rnY1yQZEt7jeZR5srratBFcV2ywdWaoDNuAMvO1Jor1fNfomF6bIkpc
 r1Kx3CTr7m+MB5c59HsMs7DK+IU2q0zNWigvKZ+xFQvf/zzcauy7G+fw7VQapEAxbLhL
 4Z7utBW5nuA40Ux1A71S3RlvITAox3uPRAl5S2MFw1YJY5M194o0QIDQX3wGtcLME/eJ
 Oy4w==
X-Gm-Message-State: AFqh2kqB/UzRuZLUwaqu9mnm8nkVkxNs2qlYrthF9gyQMTO7NVn7H704
 0O3N7GioUD3BRltZF77bLly6Fzy/yN+cyhS++PJRMZridM8=
X-Google-Smtp-Source: AMrXdXsVK3mJ5D/ERqiMqHkgfIEGNqRQhVBzpcMN8/oMLd3jSar12C5bTwKQvnkCxGsIy451jMSHyIVylh8xSHvub1U=
X-Received: by 2002:a17:906:c302:b0:85a:e45c:65f7 with SMTP id
 s2-20020a170906c30200b0085ae45c65f7mr1729343ejz.123.1674168586000; Thu, 19
 Jan 2023 14:49:46 -0800 (PST)
MIME-Version: 1.0
References: <afde051e-4e63-368c-3251-70f829a51c4e@achow101.com>
 <Y8ZSXrxfR8HrB8zD@erisian.com.au>
 <CAGpPWDbLC-om+SR5boRv8U0RptqRUMYJhYvnLbpvm3AKOuX4Fg@mail.gmail.com>
 <CAPfvXf+GaJ-fO9TJVpSaKKhQU79p7krzFQg7+92PA5wHS3ps0Q@mail.gmail.com>
In-Reply-To: <CAPfvXf+GaJ-fO9TJVpSaKKhQU79p7krzFQg7+92PA5wHS3ps0Q@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 19 Jan 2023 16:49:30 -0600
Message-ID: <CAGpPWDadhSxt3OsUYnDT4ee59DcXCw7wVGyV+Zu5jBx2en0eqA@mail.gmail.com>
To: "James O'Beirne" <james.obeirne@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000dcde3205f2a5bf65"
X-Mailman-Approved-At: Thu, 19 Jan 2023 23:22:08 +0000
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: Thu, 19 Jan 2023 22:49:50 -0000

--000000000000dcde3205f2a5bf65
Content-Type: text/plain; charset="UTF-8"

>> It would usually be prudent to store this recovery address with every key
to the vault, ...
> Worth noting now that in OP_VAULT the recovery path can be optionally
gated by an arbitrary scriptPubKey.

Gating by a scriptPubKey solves the problem I was talking about there.
However, thinking about it more, I realized doing this basically turns
OP_VAULT into something able to do general covenants. By making
`unvault-target-hash`
unsatisfiable (set to some random number that isn't derived from a hash)
the delay wouldn't matter, but arbitrary conditions can be set on spending
the utxo to the "recovery address" which could be another OP_UNVAULT
destination. It seems like that could be used as a general CTV-like
covenant.

>> 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

Besides space savings, there's the consideration of the usability of the
vault and downstream code complexity. One of the criteria I designed the
"efficient wallet vaults" opcodes for is that the vault spend should be
spendable in situations where a normal output is spendable as much as
possible. Having a constraint that prevents one type of otherwise spendable
output from being combined with another type would add complexity to all
downstream code which now has to have special cases - either a simple error
and recovery if they just want to disallow that type of opcode being
combined with other types (which may degrade the user experience by asking
them to provide a different utxo or do an unvaulting first), or some kind
of special case handling to make it work. Any kind of hybrid wallet
incorporating a vault (eg a wallet that combines a vault and a hot address
or lightning channel, kind of like Phoenix combines a lightning channel and
a normal onchain wallet) would need to deal with this kind of extra
complexity during utxo selection.

Are there currently any situations where one otherwise-spendable utxo can't
be mixed with another? If not, this added edge case deserves some extra
consideration I think.

> 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.

I agree that's doable. I just think it merits some consideration as to
whether that complexity (both for downstream code and for users) is a
favorable trade off vs having a solution to reasonably bound fees spendable
from the vault.

Consider the case where a self-custodying user would have a small set of
keys (2? 3?) and use all those keys to secure their vault, and just 1 of
them to secure their hot wallet. It doesn't seem an implausible case and I
could imagine that kind of set up becoming quite common. In such a case, if
the hot wallet key is stolen, it means one vault key is also stolen and the
hot wallets funds could be stolen at the same time as an unvaulting is
triggered. The need to figure out how to coordinate a 3rd party's help to
recover is at best an added difficulty and delay.

An alternative would be to keep a completely separate hot wallet key that
isn't use as part of the vault. But because key storage is by far the most
difficult and costly part of self-custody, every additional key that needs
to be stored is a significant additional burden (that's one of the benefits
of wallet vaults - fewer seeds needed for a given amount of
security/redundancy).

Another alternative would be to have a hot wallet that for its primary
spend-path uses a memory-only passphrase on one of the vault seeds (so
compromise of a vault seed won't compromise the hot wallet) and has a
recovery spend path that uses multiple (or all) vault seeds to recover if
you forget the passphrase. It certainly seems like something can be worked
out here to make the end user experience reasonable, but the additional
operational complexity this would entail still deserves consideration.

>> OP_BEFOREBLOCKVERIFY
> I think this breaks fundamental reorgability of transactions.

I discuss this in the Reorg Safety section here
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#reorg-safety>
.

>> This is done by using a static intermediate address that has no values
>> that are unique to the particular wallet vault address.
> Does mean .. that (ii) .. in order to be batch unvaulted [with dynamic
unvaulting
targets], vaulted
> coins need to first be spent into this intermediate output?

It does support dynamic unvaulting using OP_PUSHOUTPUTSTACK
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>,
which adds data to an output that carries over to the execution when
spending the output created by a utxo that uses OP_PUSHOUTPUTSTACK. So the
design is done such that once the intermediate output has been confirmed
and the unvaulting delay has passed, it is then fully owned by the
recipient without a second transaction (because of the use of
OP_BEFOREBLOCKVERIFY). If OP_BEFOREBLOCKVERIFY is deemed to be
unacceptable, then the intermediate output is fully intermediate and a 2nd
transaction would be required to get it to its committed recipient.

> it'd be valuable to see a full implementation

While OP_BEFOREBLOCKVERIFY can be dropped with only somewhat minor degraded
usability, OP_PUSHOUTPUTSTACK is necessary for the proposal to work as
intended. I would want to see some support for the high-level concepts it
introduces before spending significant time on an implementation. It does
something fundamentally new that other opcodes haven't done: add "hidden"
data onto the output that allows for committing to destination addresses.
Maybe something along the line of Greg Sanders' suggestion for your
proposal could replace the need for this, but I'm not sure its possible
with how OP_CD is designed.

On Wed, Jan 18, 2023 at 5:38 PM James O'Beirne <james.obeirne@gmail.com>
wrote:

> > 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.
>

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

<div dir=3D"ltr"><span style=3D"color:rgb(80,0,80)">&gt;&gt; It would usual=
ly be prudent to store this recovery address with every=C2=A0</span>key to =
the vault, ...<br>&gt; Worth noting now that in OP_VAULT the recovery path =
can be optionally gated by an arbitrary scriptPubKey.<br><div><br></div><di=
v>Gating by a scriptPubKey solves the problem I was talking about there. Ho=
wever, thinking about it more, I realized doing this basically turns OP_VAU=
LT into something able to do general covenants. By making=C2=A0<span style=
=3D"color:rgb(0,0,0);white-space:pre-wrap">`unvault-target-hash` unsatisfia=
ble (set to some random number that isn&#39;t derived from a hash) the dela=
y wouldn&#39;t matter, but arbitrary conditions can be set on spending the =
utxo to the &quot;recovery address&quot; which could be another OP_UNVAULT =
destination. It seems like that could be used as a general CTV-like covenan=
t.</span></div><div><br></div><div><span style=3D"color:rgb(80,0,80)">&gt;&=
gt; Wouldn&#39;t it be reasonably possible to allow recovery outputs with a=
ny<br>&gt;&gt; recovery address to be batched, and the amount sums sent to =
each to be<br>&gt;&gt; added up and verified?</span><br></div><div>&gt; I t=
hink the space savings from this is pretty negligible<br></div><div><br></d=
iv><div>Besides space savings, there&#39;s the consideration of the usabili=
ty of the vault and downstream code complexity. One of the criteria I desig=
ned the &quot;efficient wallet vaults&quot; opcodes for is that the vault s=
pend should be spendable in situations where a normal output is spendable a=
s much as possible. Having a constraint that prevents one type of otherwise=
 spendable output from being combined with another type would add complexit=
y to all downstream code which now has to have special cases - either a sim=
ple error and recovery if they just want to disallow that type of opcode be=
ing combined with other types (which may degrade the user experience by ask=
ing them to provide a different utxo or do an unvaulting first), or some ki=
nd of special case handling to make it work. Any kind of hybrid wallet inco=
rporating a vault (eg a wallet that combines a vault and a hot address or l=
ightning channel, kind of like Phoenix combines a lightning channel and a n=
ormal onchain wallet) would need to deal with this kind of extra complexity=
 during utxo selection.=C2=A0</div><div><br></div><div>Are there currently =
any situations where one otherwise-spendable utxo can&#39;t be mixed with a=
nother? If not, this added edge case deserves some extra consideration I th=
ink.</div><div><br></div><div>&gt; 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.</di=
v><div><br><div>I agree that&#39;s=C2=A0doable. I just think it merits some=
 consideration as to whether that complexity (both for downstream code and =
for users) is a favorable trade off vs having a solution to reasonably boun=
d fees spendable from the vault.=C2=A0</div><div><br></div><div>Consider th=
e case where a self-custodying user would have a small set of keys (2? 3?) =
and use all those keys to secure their vault, and just 1 of them to secure =
their hot wallet. It doesn&#39;t seem an implausible case and I could imagi=
ne that kind of=C2=A0set up becoming quite common. In such a case, if the h=
ot wallet key is stolen, it means one vault key is also stolen and the hot =
wallets funds could be stolen at the same time as an unvaulting is triggere=
d. The need to figure out how to coordinate a 3rd party&#39;s help to recov=
er is at best an added difficulty and delay.=C2=A0</div><div><br></div><div=
>An alternative would be to keep a completely separate hot wallet key that =
isn&#39;t use as part of the vault. But because key storage is by far the m=
ost difficult and costly part of self-custody, every additional key that ne=
eds to be stored is a significant additional burden (that&#39;s one of the =
benefits of wallet vaults - fewer seeds needed for a given amount of securi=
ty/redundancy).=C2=A0</div><div><br></div><div>Another alternative would be=
 to have a hot wallet that for its primary spend-path uses a memory-only pa=
ssphrase on one of the vault seeds (so compromise of a vault seed won&#39;t=
 compromise the hot wallet) and has a recovery spend path that uses multipl=
e (or all) vault seeds to recover if you forget the passphrase. It certainl=
y seems like something can be worked out here to make the end user experien=
ce reasonable, but the additional operational complexity this would entail =
still deserves consideration.</div><div><br></div><div>&gt;&gt; OP_BEFOREBL=
OCKVERIFY</div>&gt; I think this breaks fundamental reorgability of transac=
tions.<div><br></div></div><div>I discuss this in <a href=3D"https://github=
.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblock=
verify.md#reorg-safety" target=3D"_blank">the Reorg Safety section here</a>=
.</div><div><br></div><div>&gt;&gt; This is done by using a static intermed=
iate address that has no values</div>&gt;&gt; that are unique to the partic=
ular wallet vault address.<br>&gt; Does mean .. that=C2=A0(ii) .. in order =
to be batch unvaulted [with dynamic unvaulting<br>targets], vaulted<br>&gt;=
 coins need to first be spent into this intermediate output?<div><br></div>=
<div>It does support dynamic unvaulting using <a href=3D"https://github.com=
/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack=
.md" target=3D"_blank">OP_PUSHOUTPUTSTACK</a>, which adds data to an output=
 that carries over to the execution when spending the output created by a u=
txo that=C2=A0uses OP_PUSHOUTPUTSTACK. So the design is done such that once=
 the intermediate output has been confirmed and the unvaulting delay has pa=
ssed, it is then fully owned by the recipient without a second transaction =
(because of the use of OP_BEFOREBLOCKVERIFY). If OP_BEFOREBLOCKVERIFY is de=
emed to be unacceptable, then the intermediate output is fully intermediate=
 and a 2nd transaction would be required to get it to its committed recipie=
nt.</div><div><br></div><div>&gt; it&#39;d be valuable to see a full implem=
entation<br></div><div><br></div><div>While OP_BEFOREBLOCKVERIFY can be dro=
pped with only somewhat minor degraded usability, OP_PUSHOUTPUTSTACK is nec=
essary for the proposal to work as intended. I would want to see some suppo=
rt for the high-level concepts it introduces before spending significant ti=
me on an implementation. It does something fundamentally new that other opc=
odes haven&#39;t done: add &quot;hidden&quot; data onto the output that all=
ows for committing to destination addresses. Maybe something along the line=
 of Greg Sanders&#39; suggestion for your proposal could replace the need f=
or this, but I&#39;m not sure its possible with how OP_CD is designed.=C2=
=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Wed, Jan 18, 2023 at 5:38 PM James O&#39;Beirne &lt;<a href=3D"=
mailto:james.obeirne@gmail.com" target=3D"_blank">james.obeirne@gmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv 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 out=
put uses an appropriate OP_UNVAULT<br>&gt; script.<br><br>It&#39;s probably=
 quicker for you to just read through the<br>implementation that I referenc=
e in the last section of the paper.<br><br><a href=3D"https://github.com/bi=
tcoin/bitcoin/blob/fdfd5e93f96856fbb41243441177a40ebbac6085/src/script/inte=
rpreter.cpp#L1419-L1456" target=3D"_blank">https://github.com/bitcoin/bitco=
in/blob/fdfd5e93f96856fbb41243441177a40ebbac6085/src/script/interpreter.cpp=
#L1419-L1456</a><br><br>&gt; It would usually be prudent to store this reco=
very address with every<br>&gt; key to the vault, ...<br><br>I&#39;m not su=
re I really follow here. Worth noting now that in OP_VAULT the<br>recovery =
path can be optionally gated by an arbitrary scriptPubKey.<br><br>&gt; This=
 is rather limiting isn&#39;t it? Losing the key required to sign<br>&gt; l=
oses your recovery option. <br><br>This functionality is optional in OP_VAU=
LT as of today. You can specify<br>OP_TRUE (or maybe I should allow empty?)=
 in the &lt;recovery-params&gt; to<br>disable any signing necessary for rec=
overy.<br><br>&gt; Wouldn&#39;t it be reasonably possible to allow recovery=
 outputs with any<br>&gt; recovery address to be batched, and the amount su=
ms sent to each to be<br>&gt; added up and verified?<br><br>I think the spa=
ce savings from this is pretty negligible, since you&#39;re<br>just saving =
on the transaction overhead, and it makes the implementation<br>decently mo=
re complicated. One benefit might be sharing a common<br>fee-management out=
put (e.g. ephemeral anchor) across the separate vaults<br>being recovered.<=
br><br>&gt; If someday wallet vaults are the standard wallet construct, peo=
ple<br>&gt; might not even want to have a non-vault wallet just for use in<=
br>&gt; unvaulting. <br><br>If you truly lacked any non-vaulted UTXOs and c=
ouldn&#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 unvault trigger<br>transaction, and they provide a spend of the =
ephemeral output.<br><br>Though you do raise a good point that this constru=
ction as written may<br>not be compatible with SIGHASH_GROUP... I&#39;d hav=
e to think about that<br>one.<br><br>&gt; Hmm, it seems inaccurate to say t=
hat step is &quot;skipped&quot;. While there<br>&gt; isn&#39;t a warm walle=
t step, its replaced with an OP_UNVAULT script step. <br><br>It is &quot;sk=
ipped&quot; in the sense that your bitcoin can&#39;t be stolen by having<br=
>to pass through some intermediate wallet during an authorized withdrawal<b=
r>to a given target, in the way that they could if you had to prespecify<br=
>an unvault target 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 the block the transaction is<br>&gt; within has a block heig=
ht below a particular number. This allows a<br>&gt; spend-path to expire.<b=
r><br>I think this 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>controvers=
ial.<br><br>&gt; This is done by using a static intermediate address that h=
as no values<br>&gt; that are unique to the particular wallet vault address=
. <br><br>Does mean either that (i) this proposal doesn&#39;t have dynamic =
unvaulting<br>targets or, (ii) if you do, in order to be batch unvaulted, v=
aulted<br>coins need to first be spent into this intermediate output?<br><b=
r>It sounds like (ii) is the case, given that your unvault target<br>specif=
ication lives in (I think?) the witness for the spend creating the<br>inter=
mediate output.<br><br>If the intermediate address doesn&#39;t have any val=
ues which are unique to<br>a particular vault, how do you authorize recover=
ies from it? <br><br>---<br><br>Personally I think if you&#39;d like to pur=
sue your proposal, it&#39;d be<br>valuable to see a full implementation. Mi=
ght also make it easier to<br>assess the viability of the proposal.</div></=
div>
</blockquote></div>

--000000000000dcde3205f2a5bf65--