path: root/f7/dda596e93b63d4a365917327f586f0a23158d9

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 705E9C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 18 Jan 2023 19:00:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 3E30840620
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 18 Jan 2023 19:00:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3E30840620
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=XuktpAzN
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 6m1mYB5kPHCK
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 18 Jan 2023 19:00:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 073D9404BB
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [IPv6:2a00:1450:4864:20::52b])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 073D9404BB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 18 Jan 2023 19:00:47 +0000 (UTC)
Received: by mail-ed1-x52b.google.com with SMTP id z11so10930ede.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 18 Jan 2023 11:00: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=wN5K5XaTFYBV+VsxdUsqyBhelXkChF5j4wiWHYEU36o=;
 b=XuktpAzNiP54kepR7Zr1dW0eITIsaOXdniI0zLwhPGb+ED3ENm96uRmI5Sri6Oqtgl
 Akyx6pfVo0F3xw4cFG3QcvvugsBvzoVGQWLBiFXI2SdGwKQVmW9iDXyhUZZwcf9+45aV
 O6Bl+izYn6H/jRz6V+sdXZ09xagIu8KRwvvB8JIBPVggZD3Aj5/4ZTNVI+vtlV9YfBDa
 nXGFOtBSdaJBzyfyo1zyGW3CKrKkYJVr/MvCG1059/LlOeaSBT4pn8gmGTOCgD7kJ76v
 24neoUQk8xfHvRQscXAMYygUMWLLleryw4nnfucknGjwgTYOPrR7MFGQVSliokDBn/TB
 vRQw==
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=wN5K5XaTFYBV+VsxdUsqyBhelXkChF5j4wiWHYEU36o=;
 b=Lhus6wo9UZxLmXipBUnsj7tG/5gmLutNlwjTV2M+ETXKqtxOIeskdEUx1ujUEk7g7G
 yWXEP72laxf4NrKAABlNf1Ny0ctbf4CYu/Lxi715erxj2lBQdTjIZ8vLgrWBJLaYWDbi
 ZO2WnOroeWne6OuhHXhvt2JwjcUfkFPdxIh8s/VjO0VuDSGqratJvL4izE7toQb/X30z
 XW8KYziRUZGsDBbvzioYpm/YlPQvKxzCh0dafSHfCGe/FdlqZ3nH4K/pPhS65wEm71HY
 7MlvCF8hrp5Lymlblt8dxOPYPiiG4+hYl2RyvJm2Zz1o0MXmvnZOqsrQSRDOsFnF7+2S
 8Wtw==
X-Gm-Message-State: AFqh2koqdvA/UpaBpMVc1ZdikAV+dFDEpP3g/mkcr5RV6n8dbfidUmrQ
 kgPoOUjgks0qytoONRRDp9mPgU2KPUAeQBdU+qBSd7KbawY=
X-Google-Smtp-Source: AMrXdXvvogaqQfRP7Z15vJexuzCFa9Bj69o0vW+Ba+BsQ7BUtkcizzd0qScdgsSK0rmiOceR5qck/KGStGz7Hms6iSY=
X-Received: by 2002:aa7:d701:0:b0:49d:a2c0:90db with SMTP id
 t1-20020aa7d701000000b0049da2c090dbmr793060edq.324.1674068445989; Wed, 18 Jan
 2023 11:00:45 -0800 (PST)
MIME-Version: 1.0
References: <afde051e-4e63-368c-3251-70f829a51c4e@achow101.com>
 <Y8ZSXrxfR8HrB8zD@erisian.com.au>
In-Reply-To: <Y8ZSXrxfR8HrB8zD@erisian.com.au>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 18 Jan 2023 13:00:29 -0600
Message-ID: <CAGpPWDbLC-om+SR5boRv8U0RptqRUMYJhYvnLbpvm3AKOuX4Fg@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000d8fed05f28e6fdb"
X-Mailman-Approved-At: Wed, 18 Jan 2023 19:46:03 +0000
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 19:00:50 -0000

--0000000000000d8fed05f28e6fdb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I like the proposal of a targeted wallet vault opcode. It keeps things
constrained, limiting objections to those of the form "but if we had X it
would do all this and more so why add this complexity when it will be
obsoleted in the future?"

> An idealized vault
> no existing vault design meets this set of features.

My proposal for efficient wallet vaults
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> was designed
to meet all of those criteria, and allows batching as well. It also allows
sending in a single transaction vs the two it would take with OP_VAULT and
several other benefits. However, it uses a general covenant opcode to do
it, along with several other new opcodes specified in that write up.

>  it must first be spent into an OP_UNVAULT output

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. I see
you mentioned above (but not in the write up) that the script pub key needs
to be bare. But it would be very helpful if you detailed exactly how this
is intended to be done in that document.

It seems that Greg Sanders noticed the same thing. I like his suggestion as
you reworded it above, makes a lot of sense.

> I think the fix is just requiring a single additional witness data item
during OP_VAULT spend (for unvault path), mandating the
<target-outputs-hash> to be included in the witness stack as an input to
OP_VAULT opcode, and transaction introspection then checks to make sure the
witness item and the corresponding output script template matches the
expected.

>  If it becomes necessary to make use of the recovery path, the recovery
scriptPubKey will be revealed, which means that any other vaults with that
recovery path may be swept there by an unauthenticated party.

Another issue is that the recovery path becomes the easiest mechanism of
attack. It would usually be prudent to store this recovery address with
every key to the vault, and potentially in other places as well, so as to
minimize the possibility that the funds are lost or stolen. In such a
situation, this means that an attacker that finds any key can grief the
vault by spending it to its recovery address. My "efficient wallet vault"
design I mentioned above doesn't have this issue, nor the associated
batching DoS attack.

> if the recovery path should be committed with a signature
> This would enable a "sign-to-recover" flow at the option of the user,
specified during vault creation.

This is rather limiting isn't it? Losing the key required to sign loses
your recovery option. Seems brittle. It seems better to me to include a
<recovery-initiation-spk-hash> that operates similarly to
<recovery-spk-hash> - where some arbitrary script must be fulfilled to
allow the recovery path to be spent. For a recovery path, you'd probably
often want one of the keys required to spend from the recovery address,
since without access to one of those keys, you can't spend from the
recovery address anyway (and the spend path is an effective burn). Having
some ability to allow an n-of-m situation for triggering the recovery path
seems desirable.

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

A more arbitrary construct here that allows you to use any kind of recovery
script would be much more flexible and preclude the need for any kind of
switching like this. It seems like it would also solve the issue Andrew
Chow mentioned where recovery transactions can only be batched if they all
share the same recovery output, since each output can simply include the
appropriate witness matching its recovery scriptPubkey.

Tho I don't think I quite understand why you mention the constraint
requiring recovery batching to only be done with vault outputs that have
matching recovery destinations. 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?

>  1. script validation rules could require some allowable =E2=80=9Crange=
=E2=80=9D of
amount discounts
>  seems like a bad design

> 2. script validation rules could require that the unvault/recovery
outputs preserve the full value
> seems like the preferable approach

Both have tradeoffs. I would not call #1 an inherently bad design. I would
point out that for 2, disallowing the spending of vault funds without
access to already-unvaulted bitcoin seems like a very inconvenient design,
since it would require you in the best of cases to create more complex
transactions (or cpfp transaction chains) involving a 2nd wallet that you
involve in the unvaulting process, and in the worst case (if you have no
other bitcoin or other money on hand) you have to go asking a 3rd party for
their bitcoin to use in the unvaulting process. 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.

#1 is the approach I used to design OP_LIMITFEECONTRIBUTION
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/lfc/=
bip-limit-fee-contribution.md>,
which allows for a fee-range specification that depends on recent median
fees included in blocks. This allows rather flexibly limiting fees to a
particular range of "priorities" regardless of fee environment.

For #2, it seems like Jeremy Rubin's Sponsor transactions would be ideal
for facilitation of adding a fee to an unvaulting transaction.

>  In the case of a withdrawal, unvaulted funds can skip the =E2=80=9Cwarm=
=E2=80=9D wallet
step that precomputed vault funds must pass through on their way to
destinations only known at unvault time.

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. So its not
skipped as much as modified I think, right?

It looks like the way the OP_UNVAULT is specified prevents any use where
you don't know the full set of outputs, which might happen in cases where
certain sighash flags might be useful (signing some outputs you know, but
allowing outputs that you don't know to be added later). This is another
thing my "efficient wallet vault" design should allow.





On Tue, Jan 17, 2023 at 1:47 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Jan 16, 2023 at 11:47:09PM +0000, Andrew Chow via bitcoin-dev
> wrote:
> > It seems like this proposal will encourage address reuse for vaults,
>
> (That is listed as an explicit goal: "A single vault scriptPubKey should
> be able to "receive" multiple deposits")
>
> > However the current construction makes it impossible to spend these
> > vaults together. Since OP_VAULT requires the recovery script of the
> > unvault output to match what's provided in the input,
>
> I don't think this part is a big problem -- the recovery path requires
> revealing a secret, but if you separate that secret from the recovery
> path sPK, you could vary the secret. ie:
>
>   unvault1 delay recovery1 VAULT
>   unvault2 delay recovery2 VAULT
>
> where recovery1 =3D SHA256(SHA256(secret1), rSPK) and recovery2 =3D
> SHA256(SHA256(secret2), rSPK), and both are spendable when the top stack
> element is secretN and the first output pays at least the sum of all
> the OP_VAULT using inputs to rSPK. So batched recovery could work fine,
> I think.
>
> (If you're using the same "recovery" parameter to each VAULT, then
> you're revealing which txs are in your vault at spend time, rather than
> at receive time, which doesn't seem all that much better to me)
>
> But the problem with this is it prevents you from combining vaults when
> spending normally: so if you've got a bunch of vaults with 1 BTC each,
> and want to spend 10 BTC on a house, you'll need to make 11 separate
> transactions:
>
>   * 10 txs each spending a single vault utxo, satisfying
>       <uN> <delay> <rN> OP_VAULT
>     via the uN path, creating an output of
>       <outhash> <delay> <rN> OP_UNVAULT
>
>   * 1 tx spending all the OP_UNVAULT outputs to a common set of outputs
>     <uN>, with nSequence set to a relative timelock of at least <delay>
>
> Whereas if you use an identical OP_VAULT script for all the utxos in
> your vault, that can look like:
>
>   * 1 tx, spending all the vault utxos, to a single OP_UNVAULT output,
>     with the same <delay> <rN> that all the inputs share.
>
>   * 1 tx spending the OP_UNVAULT output after a delay
>
> But maybe you can get the best of both worlds just by having the unvault
> path for OP_VAULT require you to put the vout number for its correspondin=
g
> OP_UNVAULT output on the stack? Then if you're doing address reuse, you
> use a single vout for multiple inputs; and if you're avoiding address
> reuse, you use multiple outputs, and provide the mapping between inputs
> and outputs explicitly.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>I like the proposal of a targeted wallet vault opcode=
. It keeps things constrained, limiting=C2=A0objections to those of the for=
m &quot;but if we had X it would do all this and more so why add this compl=
exity when it will be obsoleted in the future?&quot;</div><div><br></div>&g=
t; An idealized vault<div>&gt; no existing vault design meets this set of f=
eatures.

</div><div><br></div><div>My proposal for <a href=3D"https://github.com/fre=
sheneesz/bip-efficient-bitcoin-vaults" target=3D"_blank">efficient wallet v=
aults</a>=C2=A0was designed to meet all of those criteria, and allows batch=
ing as well. It also allows sending in a single transaction vs the two it w=
ould take with OP_VAULT and several other benefits. However, it uses a gene=
ral covenant opcode to do it, along with several other new opcodes specifie=
d in that write up.=C2=A0</div><div><br></div><div>&gt;=C2=A0

it
must first be spent into an OP_UNVAULT output

</div><div><br></div><div>I don&#39;t see=C2=A0in the write up how a node v=
erifies that the destination of a spend using an OP_VAULT output uses an ap=
propriate OP_UNVAULT script. I see you mentioned above (but not in the writ=
e up) that the script pub key needs to be bare. But it would be very helpfu=
l if you detailed exactly how this is intended to be done in that document.=
=C2=A0</div><div><br></div><div>It seems that Greg Sanders noticed the same=
 thing. I like his suggestion as you reworded it above, makes a lot of sens=
e.</div><div><br></div><div>&gt; I think the fix is just requiring a single=
 additional witness data item during OP_VAULT spend (for unvault path), man=
dating the &lt;target-outputs-hash&gt; to be included in the witness stack =
as an input to OP_VAULT opcode, and transaction introspection then checks t=
o make sure the witness item and the corresponding output script template m=
atches the expected.</div><div><br></div><div>&gt;=C2=A0

If it becomes necessary to make use of the recovery path, the recovery scri=
ptPubKey will
be revealed, which means that any other vaults with that recovery path may =
be swept there by
an unauthenticated party.</div><div><br></div><div>Another issue is that th=
e recovery path becomes the easiest mechanism of attack. It would usually b=
e prudent to store this recovery address with every key to the vault, and p=
otentially in other places as well, so as to minimize the possibility that =
the funds are lost or stolen. In such a situation, this means that an attac=
ker that finds any key can grief the vault by spending it to its recovery a=
ddress. My &quot;efficient wallet vault&quot; design I mentioned above does=
n&#39;t have this issue,=C2=A0nor the associated batching DoS attack.=C2=A0=
</div><div><br></div><div>&gt;=C2=A0<span style=3D"color:rgb(36,41,47);font=
-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sa=
ns&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Seg=
oe UI Emoji&quot;;font-size:14px">if the recovery path should be committed =
with a signature</span></div><div>&gt;=C2=A0<span style=3D"color:rgb(36,41,=
47);font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot=
;Noto Sans&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&=
quot;Segoe UI Emoji&quot;;font-size:14px">This would enable a &quot;sign-to=
-recover&quot; flow at the option of the user, specified during vault creat=
ion.</span></div><div><span style=3D"color:rgb(36,41,47);font-family:-apple=
-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&quot;,Helve=
tica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&qu=
ot;;font-size:14px"><br></span></div>This is rather limiting isn&#39;t it? =
Losing the key required to sign loses your recovery option. Seems brittle. =
It seems better to me to include a &lt;recovery-initiation-spk-hash&gt; tha=
t operates similarly to &lt;recovery-spk-hash&gt; - where some arbitrary sc=
ript must be fulfilled to allow=C2=A0the recovery path to be spent. For a r=
ecovery path, you&#39;d probably often want one of the keys required to spe=
nd from the recovery address, since without access to one of those keys, yo=
u can&#39;t spend from the recovery address anyway (and the spend path is a=
n effective burn). Having some ability to allow an n-of-m situation for tri=
ggering the recovery path seems desirable.<div><div><br></div><div>&gt;=C2=
=A0

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?<br><br></div><div>A more arbitrary construct =
here that allows you to use any kind of recovery script would be much more =
flexible and preclude the need for any kind of switching like this. It seem=
s like it would also solve the issue Andrew Chow mentioned where recovery t=
ransactions can only be batched if they all share the same recovery output,=
 since each output can simply include the appropriate witness matching its =
recovery scriptPubkey.</div><div><br></div><div>Tho I don&#39;t think I qui=
te understand why you mention the constraint requiring recovery batching to=
 only be done with vault outputs that have matching recovery destinations. =
Wouldn&#39;t it be reasonably possible to allow recovery outputs with any r=
ecovery address to be batched, and the amount sums sent to each to be added=
 up and verified?</div><div>=C2=A0<div>&gt;=C2=A0 1. script validation rule=
s could require some allowable =E2=80=9Crange=E2=80=9D of amount discounts

</div><div>&gt;=C2=A0

seems like a bad design

</div><div><br></div><div>&gt; 2. script validation rules could require tha=
t the unvault/recovery outputs preserve the full
value

</div><div>&gt; seems like the preferable approach

</div><div><br></div><div>Both have tradeoffs. I would not call #1 an inher=
ently bad design. I would point out that for 2, disallowing the spending of=
 vault funds without access to already-unvaulted bitcoin seems like a very =
inconvenient design, since it would require you in the best of cases to cre=
ate more complex transactions (or cpfp transaction chains) involving a 2nd =
wallet that you involve in the unvaulting process, and in the worst case (i=
f you have no other bitcoin or other money on hand) you have to go asking a=
 3rd party for their bitcoin to use in the unvaulting process. If someday w=
allet vaults are the standard wallet construct, people might not even want =
to have a non-vault wallet just for use in unvaulting.=C2=A0</div><div><br>=
</div><div>#1 is the approach I used to design <a href=3D"https://github.co=
m/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/lfc/bip-limit-fee-cont=
ribution.md">OP_LIMITFEECONTRIBUTION</a>, which allows for a fee-range spec=
ification that depends on recent median fees included in blocks. This allow=
s rather flexibly limiting fees to a particular range of &quot;priorities&q=
uot; regardless of fee environment.=C2=A0</div><div><br></div><div>For #2, =
it seems like Jeremy Rubin&#39;s Sponsor transactions would be ideal for fa=
cilitation of adding a fee to an unvaulting transaction.</div><div><br></di=
v><div>&gt;=C2=A0

 In the
case of a withdrawal, unvaulted funds can skip the =E2=80=9Cwarm=E2=80=9D w=
allet step that precomputed vault
funds must pass through on their way to destinations only known at unvault =
time.

</div><div><br></div><div>Hmm, it seems inaccurate to say that step is &quo=
t;skipped&quot;. While there isn&#39;t a warm wallet step, its replaced wit=
h an OP_UNVAULT script step. So its not skipped as much as modified I think=
, right?</div><div><br></div><div>It looks like the way the OP_UNVAULT is s=
pecified prevents any use where you don&#39;t know the full set of outputs,=
 which might happen in cases where certain sighash flags might be useful (s=
igning some outputs you know, but allowing outputs that you don&#39;t know =
to be added later). This is another thing my &quot;efficient wallet vault&q=
uot; design should allow.=C2=A0</div><div><div><br></div><div><br></div><di=
v><br></div><div><br></div></div></div></div></div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 17, 2023 at 1:47 A=
M Anthony Towns via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
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">On=
 Mon, Jan 16, 2023 at 11:47:09PM +0000, Andrew Chow via bitcoin-dev wrote:<=
br>
&gt; It seems like this proposal will encourage address reuse for vaults,<b=
r>
<br>
(That is listed as an explicit goal: &quot;A single vault scriptPubKey shou=
ld<br>
be able to &quot;receive&quot; multiple deposits&quot;)<br>
<br>
&gt; However the current construction makes it impossible to spend these<br=
>
&gt; vaults together. Since OP_VAULT requires the recovery script of the<br=
>
&gt; unvault output to match what&#39;s provided in the input,<br>
<br>
I don&#39;t think this part is a big problem -- the recovery path requires<=
br>
revealing a secret, but if you separate that secret from the recovery<br>
path sPK, you could vary the secret. ie:<br>
<br>
=C2=A0 unvault1 delay recovery1 VAULT<br>
=C2=A0 unvault2 delay recovery2 VAULT<br>
<br>
where recovery1 =3D SHA256(SHA256(secret1), rSPK) and recovery2 =3D<br>
SHA256(SHA256(secret2), rSPK), and both are spendable when the top stack<br=
>
element is secretN and the first output pays at least the sum of all<br>
the OP_VAULT using inputs to rSPK. So batched recovery could work fine,<br>
I think.<br>
<br>
(If you&#39;re using the same &quot;recovery&quot; parameter to each VAULT,=
 then<br>
you&#39;re revealing which txs are in your vault at spend time, rather than=
<br>
at receive time, which doesn&#39;t seem all that much better to me)<br>
<br>
But the problem with this is it prevents you from combining vaults when<br>
spending normally: so if you&#39;ve got a bunch of vaults with 1 BTC each,<=
br>
and want to spend 10 BTC on a house, you&#39;ll need to make 11 separate<br=
>
transactions:<br>
<br>
=C2=A0 * 10 txs each spending a single vault utxo, satisfying<br>
=C2=A0 =C2=A0 =C2=A0 &lt;uN&gt; &lt;delay&gt; &lt;rN&gt; OP_VAULT<br>
=C2=A0 =C2=A0 via the uN path, creating an output of<br>
=C2=A0 =C2=A0 =C2=A0 &lt;outhash&gt; &lt;delay&gt; &lt;rN&gt; OP_UNVAULT<br=
>
<br>
=C2=A0 * 1 tx spending all the OP_UNVAULT outputs to a common set of output=
s<br>
=C2=A0 =C2=A0 &lt;uN&gt;, with nSequence set to a relative timelock of at l=
east &lt;delay&gt;<br>
<br>
Whereas if you use an identical OP_VAULT script for all the utxos in<br>
your vault, that can look like:<br>
<br>
=C2=A0 * 1 tx, spending all the vault utxos, to a single OP_UNVAULT output,=
<br>
=C2=A0 =C2=A0 with the same &lt;delay&gt; &lt;rN&gt; that all the inputs sh=
are.<br>
<br>
=C2=A0 * 1 tx spending the OP_UNVAULT output after a delay<br>
<br>
But maybe you can get the best of both worlds just by having the unvault<br=
>
path for OP_VAULT require you to put the vout number for its corresponding<=
br>
OP_UNVAULT output on the stack? Then if you&#39;re doing address reuse, you=
<br>
use a single vout for multiple inputs; and if you&#39;re avoiding address<b=
r>
reuse, you use multiple outputs, and provide the mapping between inputs<br>
and outputs explicitly.<br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000000d8fed05f28e6fdb--