path: root/83/682019f8d2bee9bbad15ae7d1c7cc45861e3a5

Return-Path: <james.obeirne@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1F023C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 20 Jan 2023 17:43:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id EDEB0612C0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 20 Jan 2023 17:43:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EDEB0612C0
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=MVWJcy0Y
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 9aIHc_R-Nebs
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 20 Jan 2023 17:43:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9DF07612AA
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com
 [IPv6:2607:f8b0:4864:20::22e])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 9DF07612AA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 20 Jan 2023 17:43:23 +0000 (UTC)
Received: by mail-oi1-x22e.google.com with SMTP id i5so5013983oih.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 20 Jan 2023 09:43:23 -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=Ag4Tf2SeXJHR0Egt2HKTzHfS3pzDb7qIACndMoybXC8=;
 b=MVWJcy0YcG9Jqtb8yTYGMJN+0brzdcWwHJuYz5HBBJopKGKr+Bz5tXS8uwdU5eUiuT
 wYXFP4OKOTuZcpvBE1Xe1+T8ulNCjRdYLS4stYKjDSiu2OASea/n5kMO4Gy1ijrJMT9U
 DbO9mJS7WhWkzmjO+NQjQ8cSnVz8RH+MRTW/ohaWz1yU02rcuyj7wdI3u1je1/x8mSlD
 UnCYkLTn+pw6ct8AHea98n70iQG12eEzBu+yv8e2NTUijy2yO4n2S0rp48+BswVCwxJw
 OcxpFgqmQU4mUjZh510qLPbrhKn2RJxZi1cHe0yXUtwZUBXSgua7V7pOGNthPogoNUpA
 QOlg==
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=Ag4Tf2SeXJHR0Egt2HKTzHfS3pzDb7qIACndMoybXC8=;
 b=KPO+q6wgpdaXYLG+bEkeEFiMZnPZ+HtWGceLWWckLO+zYNzawCcl/4Ynco/fK5idvZ
 INUEtMEtVztV5Z7HtNJ2xQjivLcnNBoUNVSKXmKngqnHuYu9e7UKKV7/ezNFxq/tI67Y
 Txxtue9DLFcTXkdmBt5GgQ34SCo6DhUyQfOHMjJxtvClTDU7T8mhcgC7SDUUqPTnvyg1
 pzl6I+Y/ZNzXLSOOuRSIeLLaRg11B9BkkQ3fs/THpjY/klSqZBdjhNBM/kGBSMsMZa1n
 +Mh2vp08dxrG1vUnc2Uqswjikp7aA3U9UTgNqp4EM8JB0x4zfWQ5f1zSzfnFj+hrFgRO
 hVMg==
X-Gm-Message-State: AFqh2kqO7XedZnP6RKzYoSLSHdSVmAwzh3EfHUWbiOOa7nNsQ9HeOcMk
 MDH4tSE4g6wrQmyqpRmxnO/5d6UUVB8BUyhI/+chvjdaaJSpNw==
X-Google-Smtp-Source: AMrXdXt0hxLRresyzx5f4T98RUtLcyAGIa2GD0yMvsdwBah0BA8hm1JDteBj/l+XNSsUvQkWSbPzij3/HO+34qkQuVg=
X-Received: by 2002:a05:6808:1a29:b0:364:98c7:e82d with SMTP id
 bk41-20020a0568081a2900b0036498c7e82dmr1002859oib.222.1674236602518; Fri, 20
 Jan 2023 09:43:22 -0800 (PST)
MIME-Version: 1.0
References: <afde051e-4e63-368c-3251-70f829a51c4e@achow101.com>
In-Reply-To: <afde051e-4e63-368c-3251-70f829a51c4e@achow101.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Fri, 20 Jan 2023 12:43:14 -0500
Message-ID: <CAPfvXf+7WRGYOHsYT8cfsaeO+eycPVuXsK_K-Kpe7vLUEL=6AQ@mail.gmail.com>
To: Andrew Chow <lists@achow101.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f691ff05f2b59502"
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: Fri, 20 Jan 2023 17:43:25 -0000

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

Andrew, thanks for taking the time.

> It seems like this proposal will encourage address reuse for vaults,
> at least in some parts. It seems like it would not be difficult to
> ensure that each vault address was unique through the use of key
> derivation.

I think it's worth stepping back and noting that this proposal defers
the level of privacy-vs.-efficiency to be decided by the end user.

For users who are very privacy conscious and are doing fairly low volume
(a few vaulted coins a month?), trading the ability to do batched
operations for no privacy loss seems reasonable. They can use a ranged
descriptor to generate recovery paths and unvault sPKs and reveal no
marginal information during recoveries or unvaults.

Though of course there still may be an obvious temporal association
across transactions in the case of recovery - everything with the same
unvault key has to be recovered at once.

For users who expect to have large numbers of vaulted coins and maybe
don't care as much about privacy (e.g. many commercial users), revealing
the related nature of coins that are being unvaulted or recovered seems
like an okay cost to pay. Such users might decide to create "tranches"
of vaults with different parameters in whatever manner makes sense for
their use.

Importantly: in either case, you can always keep the nature of
still-vaulted coins hidden by burying the OP_VAULT script in a taptree
and varying the internal key you use for each coin with a ranged
descriptor. This way, only the revealed contents of unvaults and
recoveries can be associated. So I think that's your worst case, which
really doesn't seem bad to me.

As an aside, a goal in supporting address reuse wasn't for address reuse
*per se* - it was to remove potential catastrophe resulting from the
case where you give someone a vault address to deposit to, and they wind
up depositing to it multiple times - whether you warned them against it
or not.


> I'm not sure how [batching without privacy loss] could be solved
> though.

For recovery, I think it might be intractable at the moment.

Seemingly unrelated vaults which have the same recovery parameters will
presumably be recovered together if the unvault key is compromised. The
simple fact that these outputs are being spent together and are OP_VAULT
scripts fundamentally reveals their association during recovery, no way
around that AFAICT.

Similarly for the unvaulting, you can't get around revealing that you're
spending a group of outputs that contain an OP_VAULT script.

As mentioned above, unvaulting -- regardless of whether your vault
configuration supports batching or not -- *never* has to correlate
unvaulted coins to still-vaulted coins if you are either

  (i) varying the internal key used for the OP_VAULT taptrees, or
  (ii) using the optional "authorized recovery" feature and are varying
       that sPK with a ranged descriptor.

So there's really never a case where unvaults have to reveal a
relationship to, or between, still-vaulted coins. Subsequent unvaults
may be able to be correlated though on the basis of the recovery sPK
target hash.


> It just means that the recovery scripts must be the same, and this
> would leave an identifying mark on chain for every unvault.

This is only true if the user decides to create vaults which share
"literal" recovery paths. At the risk of belaboring the point for
clarity, you can avoid this by generating the different "literal"
recovery paths from a ranged descriptor which is controlled by a single
private key -- of course at the cost of no batched recovery.


> not to mention that sweeping to recovery would also reveal all of your
> coins too.

Maybe it's worth contextualizing that recovery sweeps really only happen
as a final fallback in catastrophic cases that, in a world without
vaults, would result in the coins simply being stolen. In this case I
would guess most users are willing to make the privacy trade to retain
ownership of their coins.


> I think it would be sufficient to do the same check as the OP_UNVAULT
> script [when validating the revault output in the unvault trigger
> transaction] and just require that the recovery script and the delay
> are the same

Consider that this allows the holder of the unvault key (possibly an
attacker) to immediately spend the vault into a new vault configuration
with a different unvault key.

Obviously the recovery path would still be the same, and so the owner of
the vault could still sweep if the unvault key switch was unauthorized,
but I'll need to think a little bit more about whether this change is
more fundamental.

Generally that would be easy to implement, though. I'll think on it. My
suspicion is that you're right and this would be a good change.


> I'm also not convinced that OP_VAULT and OP_UNVAULT should be allowed
> for bare and P2WSH outputs. It seems like it would make sense to just
> limit their usage to tapscripts as this would simply their
> implementation.

I think you're right, and accordingly I'll shortly be reimplementing
this with OP_SUCCESSx overrides instead of OP_NOPs. I'd be curious to
know if anyone has any objections to this - i.e. if there's a solid case
for vaults in a pre-taproot context.

James

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

<div dir=3D"ltr"><div dir=3D"ltr">Andrew, thanks for taking the time.<br><b=
r>&gt; It seems like this proposal will encourage address reuse for vaults,=
<br>&gt; at least in some parts. It seems like it would not be difficult to=
<br>&gt; ensure that each vault address was unique through the use of key<b=
r>&gt; derivation.<br><br>I think it&#39;s worth stepping back and noting t=
hat this proposal defers<br>the level of privacy-vs.-efficiency to be decid=
ed by the end user. <br><br>For users who are very privacy conscious and ar=
e doing fairly low volume<br>(a few vaulted coins a month?), trading the ab=
ility to do batched<br>operations for no privacy loss seems reasonable. The=
y can use a ranged<br>descriptor to generate recovery paths and unvault sPK=
s and reveal no<br>marginal information during recoveries or unvaults. <br>=
<br>Though of course there still may be an obvious temporal association<br>=
across transactions in the case of recovery - everything with the same<br>u=
nvault key has to be recovered at once.<br><br>For users who expect to have=
 large numbers of vaulted coins and maybe<br>don&#39;t care as much about p=
rivacy (e.g. many commercial users), revealing<br>the related nature of coi=
ns that are being unvaulted or recovered seems<br>like an okay cost to pay.=
 Such users might decide to create &quot;tranches&quot;<br>of vaults with d=
ifferent parameters in whatever manner makes sense for<br>their use.<br><br=
>Importantly: in either case, you can always keep the nature of<br>still-va=
ulted coins hidden by burying the OP_VAULT script in a taptree<br>and varyi=
ng the internal key you use for each coin with a ranged<br>descriptor. This=
 way, only the revealed contents of unvaults and<br>recoveries can be assoc=
iated. So I think that&#39;s your worst case, which<br>really doesn&#39;t s=
eem bad to me.<br><br>As an aside, a goal in supporting address reuse wasn&=
#39;t for address reuse<br>*per se* - it was to remove potential catastroph=
e resulting from the<br>case where you give someone a vault address to depo=
sit to, and they wind<br>up depositing to it multiple times - whether you w=
arned them against it<br>or not.<br><br><br>&gt; I&#39;m not sure how [batc=
hing without privacy loss] could be solved<br>&gt; though.<br><br>For recov=
ery, I think it might be intractable at the moment. <br><br>Seemingly unrel=
ated vaults which have the same recovery parameters will<br>presumably be r=
ecovered together if the unvault key is compromised. The<br>simple fact tha=
t these outputs are being spent together and are OP_VAULT<br>scripts fundam=
entally reveals their association during recovery, no way<br>around that AF=
AICT.<br><br>Similarly for the unvaulting, you can&#39;t get around reveali=
ng that you&#39;re<br>spending a group of outputs that contain an OP_VAULT =
script. <br><br>As mentioned above, unvaulting -- regardless of whether you=
r vault<br>configuration supports batching or not -- *never* has to correla=
te<br>unvaulted coins to still-vaulted coins if you are either<br><br>=C2=
=A0 (i) varying the internal key used for the OP_VAULT taptrees, or<br>=C2=
=A0 (ii) using the optional &quot;authorized recovery&quot; feature and are=
 varying <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0that sPK with a ranged descriptor.<=
br><br>So there&#39;s really never a case where unvaults have to reveal a<b=
r>relationship to, or between, still-vaulted coins. Subsequent unvaults<br>=
may be able to be correlated though on the basis of the recovery sPK<br>tar=
get hash.<br><br><br>&gt; It just means that the recovery scripts must be t=
he same, and this<br>&gt; would leave an identifying mark on chain for ever=
y unvault.<br><br>This is only true if the user decides to create vaults wh=
ich share<br>&quot;literal&quot; recovery paths. At the risk of belaboring =
the point for<br>clarity, you can avoid this by generating the different &q=
uot;literal&quot;<br>recovery paths from a ranged descriptor which is contr=
olled by a single<br>private key -- of course at the cost of no batched rec=
overy.<br><br><br>&gt; not to mention that sweeping to recovery would also =
reveal all of your<br>&gt; coins too.<br><br>Maybe it&#39;s worth contextua=
lizing that recovery sweeps really only happen<br>as a final fallback in ca=
tastrophic cases that, in a world without<br>vaults, would result in the co=
ins simply being stolen. In this case I<br>would guess most users are willi=
ng to make the privacy trade to retain<br>ownership of their coins.<br><br>=
<br>&gt; I think it would be sufficient to do the same check as the OP_UNVA=
ULT<br>&gt; script [when validating the revault output in the unvault trigg=
er<br>&gt; transaction] and just require that the recovery script and the d=
elay<br>&gt; are the same<br><br>Consider that this allows the holder of th=
e unvault key (possibly an<br>attacker) to immediately spend the vault into=
 a new vault configuration<br>with a different unvault key. <br><br>Obvious=
ly the recovery path would still be the same, and so the owner of<br>the va=
ult could still sweep if the unvault key switch was unauthorized,<br>but I&=
#39;ll need to think a little bit more about whether this change is<br>more=
 fundamental.<br><br>Generally that would be easy to implement, though. I&#=
39;ll think on it. My<br>suspicion is that you&#39;re right and this would =
be a good change.<br><br><br>&gt; I&#39;m also not convinced that OP_VAULT =
and OP_UNVAULT should be allowed<br>&gt; for bare and P2WSH outputs. It see=
ms like it would make sense to just<br>&gt; limit their usage to tapscripts=
 as this would simply their<br>&gt; implementation.<br><br>I think you&#39;=
re right, and accordingly I&#39;ll shortly be reimplementing<br>this with O=
P_SUCCESSx overrides instead of OP_NOPs. I&#39;d be curious to<br>know if a=
nyone has any objections to this - i.e. if there&#39;s a solid case<br>for =
vaults in a pre-taproot context.</div><div dir=3D"ltr"><br></div><div>James=
</div></div>

--000000000000f691ff05f2b59502--