path: root/cd/49f55dc590bb67d8ccbe75f1d0fa74c08d470f

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 C8273C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 Jan 2023 14:18:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id A384D6101A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 Jan 2023 14:18:01 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A384D6101A
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=fBY0HjvH
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 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_FONT_FACE_BAD=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 K0f5SBqYJE8A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 Jan 2023 14:18:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8B3D561011
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com
 [IPv6:2607:f8b0:4864:20::333])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 8B3D561011
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 Jan 2023 14:18:00 +0000 (UTC)
Received: by mail-ot1-x333.google.com with SMTP id
 k44-20020a9d19af000000b00683e176ab01so7022902otk.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 Jan 2023 06:18:00 -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=an42uXi+na1cMU7Hrr5IbDeOB3rQyHTL0GUJ1eDzHCg=;
 b=fBY0HjvHUqI1IH9z+Qnq/8/N+c81YgQucg8vneShlRqrgE2iZsPBC/UDjpjUK2AySm
 kT8xJp4R16iTFhu+4bz18cFAT/C3St7y0SGkYNb390dsPbFvrRRe3Bt0sLPOc8TJHNU3
 5CS7CxtAZY5Zzjct1t6v8gOI+3PlkHDmJpqdfyyDvKMdZpCzaMlsoftGGqnSSqIJGe4R
 9rHt4ykZaoEXhMGnAT3K/hScehUKPFUJJz6j1sKSBEI9n6Szu5psi6vg4idemkJNLFUe
 4JtH56LKBuuNGZa9Cws50591oKOQB70AhAmMlsWXtPXTI7wq8Q5o2E9NHkwVQ27zc/3y
 zNmw==
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=an42uXi+na1cMU7Hrr5IbDeOB3rQyHTL0GUJ1eDzHCg=;
 b=b7LrRvYcKGnO9vNcXKwWm1JV6s5CUgtzPV1+kb+EG8GjBOgYRCtpOtdf8C8wK7R4t5
 0L3O9RYLpgWSF+Kh0VVgHCcD335UlsMKzpHrTEdmPRwyOH195Etr8Q1ZEu54loIFhqaC
 1Vo5zaoLfP1y3KmjIDKNzobqmBs92fNvoQ3ODoMx5ozwFcFFah+5wjE5A0VRsGFiXzBK
 XERhveXf+bSLTBDxI7lfeAXAVKGAhHHJucyrx4E2KdjWpW8J9+YRpy7ceV4HawsO3P7w
 YChT7lgtgA5RoH4FDix0WUTCcN17eqd/oy5ljmJGpCPhDm/rLjnJD/r8P6xgthS7bOk5
 PC/w==
X-Gm-Message-State: AFqh2kqTUPWcqcM/OYwoyYqUhE+NI3BxxgOvcT6vEawMVJCBg1t683kC
 suE9Cp345LY7zkHAVM0CRjR/4AmJ8JmMiDfQvr6Ztb3troQ=
X-Google-Smtp-Source: AMrXdXuK0hDy/nD1y3gjuIbM4La2Z6pGzoYE4pA9tS/iFBYhOTyBoDEUqbkYJnel4+iF//8Qd+5DhKysyE+/TOWWE8Y=
X-Received: by 2002:a9d:6a48:0:b0:678:23c0:5f3e with SMTP id
 h8-20020a9d6a48000000b0067823c05f3emr4346289otn.347.1673360279159; Tue, 10
 Jan 2023 06:17:59 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfL65cneOabmxfOzTZq14xN4vXNaGboq_g15-frM14RqGA@mail.gmail.com>
In-Reply-To: <CAPfvXfL65cneOabmxfOzTZq14xN4vXNaGboq_g15-frM14RqGA@mail.gmail.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Tue, 10 Jan 2023 09:17:49 -0500
Message-ID: <CAPfvXfKRmhHBP8KTKsGCac4OTPydxXQPDv0LqeOrzXNxgZxfrQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000562d705f1e98d5e"
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 14:18:01 -0000

--0000000000000562d705f1e98d5e
Content-Type: text/plain; charset="UTF-8"

Forwarding in some conceptual feedback from the pull request.

From ariard:

> I've few open questions, like if the recovery path should be committed
with a signature rather than protected by a simple scriptpubkey preimage.

That's something I've wondered about too. I have to ruminate on AJ's good
post about this, but a pretty straightforward way of enabling this (at the
expense of some complexity) is to do something like "if
<recovery-path-hash> is 32 bytes, treat it as it's currently used. If it's
33 bytes, use the first byte as a parameter for how to interpret it." To
start with, an extra prefix byte of 0x00 could mean "require a witness
satisfying the scriptPubKey that hashes to the remaining 32 bytes" in the
same way we do the unvault signing. This would enable a "sign-to-recover"
flow at the option of the user, specified during vault creation.

> The current OP_VAULT implementation is using OP_NOP repurposing but this
doesn't seem compatible with Taproot-only extensions (e.g ANYPREVOUT) and
maybe a OP_SUCCESS could be used.

Yes, with Greg's suggestion of putting <target-hash> on the witness stack
during OP_VAULT (-> OP_UNVAULT) spend, we could conceivably move
OP_VAULT/OP_UNVAULT into Taproot-only OP_SUCCESSx opcodes. I haven't
thought hard about how worthwhile it is to preserve the ability to use
OP_VAULT in pre-Taproot contexts.

> There is a conceptual wonder, if a CTV and template malleability approach
wouldn't better suit the vault use-case and allow other ones, as such
better re-usability of primitives.

I dedicated a whole section of the paper ("Precomputed vaults with
covenants") to explaining why precomputed covenant mechanisms have big
shortcomings for vaults.

That said, a number of people have commented about OP_VAULT's ability to
(inefficiently) emulate CTV. I'm still very supportive of CTV, I just don't
really have any uses I personally understand inside and out aside from
vaults... so if others do, they should really post about it on this list
and we should resume working on an activation for CTV!

---

From naumenkogs:

> I'm personally not sure batching withdrawals is that compelling... It's a
nice-to-have, but I'd think about the benefits dropping this feature would
provide.

Having familiarity with a few large-scale custodial operations, I think
batching is a really big deal. And if you're going to support multiple
deposits to the same vault, no support for batching is going to result in a
lot of unnecessary output creation even as a small user if you're, e.g.,
doing weekly automated deposits from an exchange to a vault you've
configured.

Darosior comments:

> On the contrary i think the batching feature is very compelling. The
impossibility to batch Unvaults in Revault is a major drawback: it
significantly increases the cost of any realistic operation (you need one
whole additional transaction per input, and each have likely more than one
output). It also potentially increases the cost on the network (you'd
likely want some sort of anchor output on each Unvault tx, that you might
not spend, so that's 2*n outputs created with n the number of coins spent):
we definitely don't want to prevent batching. The ability to batch the
recovery transactions (what we called Emergency tx in Revault) is also very
compelling but i think your comment was only about batched withdrawals.

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

<div dir=3D"ltr">Forwarding in some conceptual feedback from the pull reque=
st.<div><br></div><div>From ariard:</div><div><br></div><div>&gt; I<span st=
yle=3D"color:rgb(36,41,47);font-family:-apple-system,BlinkMacSystemFont,&qu=
ot;Segoe UI&quot;,&quot;Noto Sans&quot;,Helvetica,Arial,sans-serif,&quot;Ap=
ple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;;font-size:14px">&#39;ve fe=
w open questions, like if the recovery path should be committed with a sign=
ature rather than protected by a simple scriptpubkey preimage.</span></div>=
<div><span style=3D"color:rgb(36,41,47);font-family:-apple-system,BlinkMacS=
ystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&quot;,Helvetica,Arial,sans-s=
erif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;;font-size:14p=
x"><br></span></div><div><span style=3D"color:rgb(36,41,47);font-family:-ap=
ple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&quot;,He=
lvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji=
&quot;;font-size:14px">That&#39;s something I&#39;ve wondered about too. I =
have to ruminate on AJ&#39;s good post about this, but a pretty straightfor=
ward way of enabling this (at the expense of some complexity) is to do some=
thing like &quot;if &lt;recovery-path-hash&gt; is 32 bytes, treat it as it&=
#39;s currently used. If it&#39;s 33 bytes, use the first byte as a paramet=
er for how to interpret it.&quot; To start with, an extra prefix byte of 0x=
00 could mean &quot;require a witness satisfying the scriptPubKey that hash=
es to the remaining 32 bytes&quot; in the same way we do the unvault signin=
g. This would enable a &quot;sign-to-recover&quot; flow at the option of th=
e user, specified during vault creation.</span></div><div><span style=3D"co=
lor: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"><br></span></div><d=
iv><span style=3D"color:rgb(36,41,47);font-family:-apple-system,BlinkMacSys=
temFont,&quot;Segoe UI&quot;,&quot;Noto Sans&quot;,Helvetica,Arial,sans-ser=
if,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;;font-size:14px"=
>&gt;=C2=A0</span><span style=3D"color:rgb(36,41,47);font-family:-apple-sys=
tem,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">The current=C2=A0</span><code class=3D"gmail-notranslate" s=
tyle=3D"box-sizing:border-box;font-family:ui-monospace,SFMono-Regular,&quot=
;SF Mono&quot;,Menlo,Consolas,&quot;Liberation Mono&quot;,monospace;font-si=
ze:11.9px;padding:0.2em 0.4em;margin:0px;white-space:break-spaces;border-ra=
dius:6px;color:rgb(36,41,47)">OP_VAULT</code><span style=3D"color:rgb(36,41=
,47);font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quo=
t;Noto Sans&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,=
&quot;Segoe UI Emoji&quot;;font-size:14px">=C2=A0implementation is using OP=
_NOP repurposing but this doesn&#39;t seem compatible with Taproot-only ext=
ensions (e.g=C2=A0</span><code class=3D"gmail-notranslate" style=3D"box-siz=
ing:border-box;font-family:ui-monospace,SFMono-Regular,&quot;SF Mono&quot;,=
Menlo,Consolas,&quot;Liberation Mono&quot;,monospace;font-size:11.9px;paddi=
ng:0.2em 0.4em;margin:0px;white-space:break-spaces;border-radius:6px;color:=
rgb(36,41,47)">ANYPREVOUT</code><span style=3D"color:rgb(36,41,47);font-fam=
ily:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&q=
uot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe U=
I Emoji&quot;;font-size:14px">) and maybe a=C2=A0</span><code class=3D"gmai=
l-notranslate" style=3D"box-sizing:border-box;font-family:ui-monospace,SFMo=
no-Regular,&quot;SF Mono&quot;,Menlo,Consolas,&quot;Liberation Mono&quot;,m=
onospace;font-size:11.9px;padding:0.2em 0.4em;margin:0px;white-space:break-=
spaces;border-radius:6px;color:rgb(36,41,47)">OP_SUCCESS</code><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">=C2=A0could b=
e used.=C2=A0</span></div><div><span style=3D"color:rgb(36,41,47);font-fami=
ly:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&qu=
ot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI=
 Emoji&quot;;font-size:14px"><br></span></div><div><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">Yes, with Greg&#39;s sugge=
stion of putting &lt;target-hash&gt; on the witness stack during OP_VAULT (=
-&gt; OP_UNVAULT) spend, we could conceivably move OP_VAULT/OP_UNVAULT into=
 Taproot-only OP_SUCCESSx opcodes. I haven&#39;t thought hard about how wor=
thwhile it is to preserve the ability to use OP_VAULT in pre-Taproot contex=
ts.</span></div><div><span style=3D"color:rgb(36,41,47);font-family:-apple-=
system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&quot;,Helvet=
ica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quo=
t;;font-size:14px"><br></span></div><div><span style=3D"color:rgb(36,41,47)=
;font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;No=
to Sans&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quo=
t;Segoe UI Emoji&quot;;font-size:14px">&gt;=C2=A0</span><span style=3D"colo=
r:rgb(36,41,47);font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI=
&quot;,&quot;Noto Sans&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color E=
moji&quot;,&quot;Segoe UI Emoji&quot;;font-size:14px">There is a conceptual=
 wonder, if a=C2=A0</span><code class=3D"gmail-notranslate" style=3D"box-si=
zing:border-box;font-family:ui-monospace,SFMono-Regular,&quot;SF Mono&quot;=
,Menlo,Consolas,&quot;Liberation Mono&quot;,monospace;font-size:11.9px;padd=
ing:0.2em 0.4em;margin:0px;white-space:break-spaces;border-radius:6px;color=
:rgb(36,41,47)">CTV</code><span style=3D"color:rgb(36,41,47);font-family:-a=
pple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&quot;,H=
elvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoj=
i&quot;;font-size:14px">=C2=A0and template malleability approach wouldn&#39=
;t better suit the vault use-case and allow other ones, as such better re-u=
sability of primitives.</span></div><div><span style=3D"color:rgb(36,41,47)=
;font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;No=
to Sans&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quo=
t;Segoe UI Emoji&quot;;font-size:14px"><br></span></div><div><span style=3D=
"color:rgb(36,41,47);font-family:-apple-system,BlinkMacSystemFont,&quot;Seg=
oe UI&quot;,&quot;Noto Sans&quot;,Helvetica,Arial,sans-serif,&quot;Apple Co=
lor Emoji&quot;,&quot;Segoe UI Emoji&quot;;font-size:14px">I dedicated a wh=
ole section of the paper</span><span style=3D"color:rgb(36,41,47);font-fami=
ly:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&qu=
ot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI=
 Emoji&quot;;font-size:14px">=C2=A0</span><span style=3D"color:rgb(36,41,47=
);font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;N=
oto Sans&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&qu=
ot;Segoe UI Emoji&quot;;font-size:14px">(&quot;Precomputed vaults with cove=
nants&quot;)</span><span style=3D"color:rgb(36,41,47);font-family:-apple-sy=
stem,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&quot;,Helvetic=
a,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;=
;font-size:14px">=C2=A0to explaining why precomputed covenant mechanisms ha=
ve big shortcomings for vaults.=C2=A0</span></div><div><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 Em=
oji&quot;,&quot;Segoe UI Emoji&quot;;font-size:14px"><br></span></div><div>=
<span style=3D"color:rgb(36,41,47);font-family:-apple-system,BlinkMacSystem=
Font,&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">Th=
at said, a number of people have commented about OP_VAULT&#39;s ability to =
(inefficiently) emulate CTV. I&#39;m still very supportive of CTV, I just d=
on&#39;t really have any uses I personally understand inside and out aside =
from vaults... so if others do, they should really post about it on this li=
st and we should resume working on an activation for CTV!</span></div><div>=
<span style=3D"color:rgb(36,41,47);font-family:-apple-system,BlinkMacSystem=
Font,&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"><b=
r></span></div><div><span style=3D"color:rgb(36,41,47);font-family:-apple-s=
ystem,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&quot;,Helveti=
ca,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot=
;;font-size:14px">---</span></div><div><span style=3D"color:rgb(36,41,47);f=
ont-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"><br></span></div><div><span style=3D"c=
olor:rgb(36,41,47);font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe=
 UI&quot;,&quot;Noto Sans&quot;,Helvetica,Arial,sans-serif,&quot;Apple Colo=
r Emoji&quot;,&quot;Segoe UI Emoji&quot;;font-size:14px">From naumenkogs:</=
span></div><div><span style=3D"color:rgb(36,41,47);font-family:-apple-syste=
m,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&quot;,Helvetica,A=
rial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;;fo=
nt-size:14px"><br></span></div><div><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">&gt;=C2=A0</span><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">I&#39;m personally not sur=
e batching withdrawals is that compelling... It&#39;s a nice-to-have, but I=
&#39;d think about the benefits dropping this feature would provide.</span>=
</div><div><span style=3D"color:rgb(36,41,47);font-family:-apple-system,Bli=
nkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&quot;,Helvetica,Arial,=
sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;;font-si=
ze:14px"><br></span></div><div><span style=3D"color:rgb(36,41,47);font-fami=
ly:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&qu=
ot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI=
 Emoji&quot;;font-size:14px">Having familiarity with a few large-scale cust=
odial operations, I think batching is a really big deal. And if you&#39;re =
going to support multiple deposits to the same vault, no support for batchi=
ng is going to result in a lot of unnecessary output creation even as a sma=
ll user if you&#39;re, e.g., doing weekly automated deposits from an exchan=
ge to a vault you&#39;ve configured.</span></div><div><span style=3D"color:=
rgb(36,41,47);font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&q=
uot;,&quot;Noto Sans&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emo=
ji&quot;,&quot;Segoe UI Emoji&quot;;font-size:14px"><br></span></div><div><=
font color=3D"#24292f" face=3D"-apple-system, BlinkMacSystemFont, Segoe UI,=
 Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji=
"><span style=3D"font-size:14px">Darosior comments:</span></font></div><div=
><font color=3D"#24292f" face=3D"-apple-system, BlinkMacSystemFont, Segoe U=
I, Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emo=
ji"><span style=3D"font-size:14px"><br></span></font></div><div><font color=
=3D"#24292f" face=3D"-apple-system, BlinkMacSystemFont, Segoe UI, Noto Sans=
, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji"><span st=
yle=3D"font-size:14px">&gt;=C2=A0</span></font><span style=3D"color:rgb(36,=
41,47);font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&q=
uot;Noto Sans&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot=
;,&quot;Segoe UI Emoji&quot;;font-size:14px">On the contrary i think the ba=
tching feature is very compelling. The impossibility to batch Unvaults in R=
evault is a major drawback: it significantly increases the cost of any real=
istic operation (you need one whole additional transaction per input, and e=
ach have likely more than one output). It also potentially increases the co=
st on the network (you&#39;d likely want some sort of anchor output on each=
 Unvault tx, that you might not spend, so that&#39;s=C2=A0</span><code clas=
s=3D"gmail-notranslate" style=3D"box-sizing:border-box;font-family:ui-monos=
pace,SFMono-Regular,&quot;SF Mono&quot;,Menlo,Consolas,&quot;Liberation Mon=
o&quot;,monospace;font-size:11.9px;padding:0.2em 0.4em;margin:0px;white-spa=
ce:break-spaces;border-radius:6px;color:rgb(36,41,47)">2*n</code><span styl=
e=3D"color:rgb(36,41,47);font-family:-apple-system,BlinkMacSystemFont,&quot=
;Segoe UI&quot;,&quot;Noto Sans&quot;,Helvetica,Arial,sans-serif,&quot;Appl=
e Color Emoji&quot;,&quot;Segoe UI Emoji&quot;;font-size:14px">=C2=A0output=
s created with=C2=A0</span><code class=3D"gmail-notranslate" style=3D"box-s=
izing:border-box;font-family:ui-monospace,SFMono-Regular,&quot;SF Mono&quot=
;,Menlo,Consolas,&quot;Liberation Mono&quot;,monospace;font-size:11.9px;pad=
ding:0.2em 0.4em;margin:0px;white-space:break-spaces;border-radius:6px;colo=
r:rgb(36,41,47)">n</code><span style=3D"color:rgb(36,41,47);font-family:-ap=
ple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,&quot;Noto Sans&quot;,He=
lvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji=
&quot;;font-size:14px">=C2=A0the number of coins spent): we definitely don&=
#39;t want to prevent batching. The ability to batch the recovery transacti=
ons (what we called Emergency tx in Revault) is also very compelling but i =
think your comment was only about batched withdrawals.</span></div></div>

--0000000000000562d705f1e98d5e--