path: root/fe/11f72fad989a1f2ee9c1adecd31964bcb5eb38

Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C5548C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Mar 2023 14:41:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 932C2610EC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Mar 2023 14:41:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 932C2610EC
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=MnJ/S3FK
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 ruWZmf6Dh9kJ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Mar 2023 14:41:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 279E8605D6
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [IPv6:2a00:1450:4864:20::531])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 279E8605D6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Mar 2023 14:41:06 +0000 (UTC)
Received: by mail-ed1-x531.google.com with SMTP id x3so62922751edb.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Mar 2023 07:41:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20210112; t=1678804864;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=3IgdBVIyxOyNydsF84H4mpTAcvkNuWiJpUyoMBzx3yk=;
 b=MnJ/S3FKKqtQAILNjc1+n8O1LWxJyxdzMXB3cECXpyXwBeZuyqNHET1j5FC7pzDVZA
 o1r5QauQGLqN8PrsRERYmar+15Dkdb+4rHaI+SaxxUwaV6CLwbm3bhgIT8jb5cagqfLg
 D1wRYndcF64DAQ0v8VfBzp6B+Sc46WL03pm0W3D9ol53X9/cRCvqf07Ysud2mgH+3DS8
 pnXiXo1c3PuCRZF7TazxrzSbVGxuUZzK9JSRd6vndMtm42eJCxha2+NX/IY2RmaGVgk4
 +q7hyAVw5/cyWTm5JqE8mwTUjQA/rkwK0raf3OHE0HR3Fflw01083wnCVbw4L1PR4fjj
 y0Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112; t=1678804864;
 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=3IgdBVIyxOyNydsF84H4mpTAcvkNuWiJpUyoMBzx3yk=;
 b=cEY+nTxtXjnldCwaCr+3YNtL+C3y2p8uFSzoR1FY94w4GrgDbbqO8kDetpCEiMHQxf
 ysQsIvaFQC1BYr9Uxt19O8ibRKC4Ep7LPQQNGDIX4XI8UXLA3YCrCGg3OVnBputBSX9l
 2a4U0DmjGGWBq2DGAc6wXZbeet8MuovWjOrDgKM70Vrf1syjbHNqbkN/U+601tZssQMZ
 h7DP5D8kqydKfhO0aspqqJ9b+XjnLgZ1lf1w/bXVzqEuwQIBCvwl5Fwo5P3kX3aKswMw
 CLYfh2ZDu1i+5Ov6BuNFR7ot4ZvH2Yn7jKEWdNUEZYNkbvw5hbtZeOOYInH4jzK1QdUC
 AV1A==
X-Gm-Message-State: AO0yUKV5DW/OjMbcVZV+5PX+aPEOu93gjBncOTgdf2S1+4lbfzfizBeh
 bvkAI9wDlrf8ingQil9+EKaYImsD37XOwjyGmHJZu5cneuevMA==
X-Google-Smtp-Source: AK7set8p8+O+/PKnUjrR1XX3MHu9DZsWcuBJqfo4Gf3upuUMfCbXVfulbiaBJQtNNN9uelQMy4oZOzX3DbVdMRH1kWo=
X-Received: by 2002:a50:aacd:0:b0:4ab:49b9:686d with SMTP id
 r13-20020a50aacd000000b004ab49b9686dmr8803892edc.1.1678804864200; Tue, 14 Mar
 2023 07:41:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAPfvXfJQKb7i8GBvTEvTTz-3dU_5mH8jOv8Nm4Q8gPt=KxrqLQ@mail.gmail.com>
 <CAB3F3DveCDz6yy-rd3ttV8+4sMufsvB+9J-qVK95yh9aLYX+Mw@mail.gmail.com>
 <ZAAqIZZO1KK32Th9@erisian.com.au>
 <CAB3F3DtGpVHkyT_=KLS42rvdP=dgnMvChhR1Rs0BHO5yOEabmw@mail.gmail.com>
 <ZA9zgqeNiCBfBGUz@console>
In-Reply-To: <ZA9zgqeNiCBfBGUz@console>
From: Greg Sanders <gsanders87@gmail.com>
Date: Tue, 14 Mar 2023 10:40:53 -0400
Message-ID: <CAB3F3Dsu8OWJfrEAUB=5rDtrmAm=N9zL1tN_r153v01k9F4LGA@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="00000000000093f42b05f6dd3708"
Subject: Re: [bitcoin-dev] BIP for OP_VAULT
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, 14 Mar 2023 14:41:12 -0000

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

Hi Brandon,

Thank you for chiming in, causing me to think a bit more deeply on the
privacy issues
and what seems possible.

> I like that in James' current PR proposal we can explicitly batch via
the implied input/output summation rules while avoiding address reuse.
If we can retain some or all of that, I think it would be good for on
chain efficiency and potentially privacy.

Rotating trigger authorization keys maintains batchability and stops
address reuse.
Remember that anytime you share any path, like recovery path, for batching,
it becomes
obvious at spend-time. Rotating inner pubkeys only doesn't seem to help
much.

Coinjoins being the other batching scenario which could benefit perhaps are
quite a heavy
lift. You'd need the recovery policy(every other branch) to be agreed upon,
have everyone unvault
to this new joint vault, then mix, and withdrawal back to the original
vault. If someone is going through
all that effort, I suspect they'll just use a NUMS to reduce fingerprinting=
.

> Many inputs with different internal keys can be combined to satisfy the
total output value for a single output, as long as their scriptpubkeys
with FLU and NUMS internal key are equal This enables avoiding address
reuse within the vault.

To reiterate, we can just cycle any key in the $trigger branch with OP_FLU,
which accomplishes the same thing.
Or in authorization-less $trigger, add a random number which is dropped.

> Many inputs with the same scriptpubkey can be combined to satisfy a
single CTV output template. This allows a user to unfsck themselves if
they initiate a withdrawal that cannot be satisfied because they didn't
send enough sats to satisfy their template.

I think that would fit the deprecated OP_FORWARD_OUTPUTS, but OP_CTV
commits to total
number of inputs to remove txid malleability. I think the real solution to
this mistake would be to hit
the big red RECOVERY button that you're relying on for vault security
anyways.

Cheers,
Greg

On Mon, Mar 13, 2023 at 3:04=E2=80=AFPM Brandon Black <freedom@reardencode.=
com>
wrote:

> Hi Gents,
>
> > > I don't think replacing the internal-public-key makes sense -- if it
> > was immediately spendable via the keypath before there's no reason for
> > it not to be immediately spendable now.
> >
> > Slavishly following the current proposal was the idea to make sure all
> > functionality was captured; I agree with this change.
>
> I think we do need to replace the internal key with a hardcoded NUMS
> point to allow us to batch multiple vault inputs which might have
> different internal keys but the same OP_FLU/OP_VAULT_TRIGGER script to
> the same time+template-restricted output.
>
> I like that in James' current PR proposal we can explicitly batch via
> the implied input/output summation rules while avoiding address reuse.
> If we can retain some or all of that, I think it would be good for on
> chain efficiency and potentially privacy.
>
> My thoughts on batching:
>
> Many inputs with different internal keys can be combined to satisfy the
> total output value for a single output, as long as their scriptpubkeys
> with FLU and NUMS internal key are equal This enables avoiding address
> reuse within the vault.
>
> Many inputs with the same scriptpubkey can be combined to satisfy a
> single CTV output template. This allows a user to unfsck themselves if
> they initiate a withdrawal that cannot be satisfied because they didn't
> send enough sats to satisfy their template.
>
> Best,
>
> --Brandon
>

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

<div dir=3D"ltr"><div>Hi Brandon,</div><div><br></div><div>Thank you for ch=
iming in, causing me to think a bit more deeply on the privacy issues</div>=
<div>and what seems possible.</div><div><br></div>&gt; I like that in James=
&#39; current PR proposal we can explicitly batch via<br>the implied input/=
output summation rules while avoiding address reuse.<br>If we can retain so=
me or all of that, I think it would be good for on<br>chain efficiency and =
potentially privacy.<div><br></div><div>Rotating trigger authorization keys=
 maintains batchability and stops address reuse.</div><div>Remember that an=
ytime you share any path, like recovery path, for batching, it becomes</div=
><div>obvious at spend-time. Rotating inner pubkeys only doesn&#39;t seem t=
o help much.</div><div><br></div><div>Coinjoins=C2=A0being the other batchi=
ng scenario which could benefit perhaps are quite a heavy</div><div>lift. Y=
ou&#39;d need the recovery policy(every other branch) to be agreed upon, ha=
ve everyone unvault</div><div>to this new joint vault, then mix, and withdr=
awal back to the original vault. If someone is going through</div><div>all =
that effort, I suspect they&#39;ll just use a NUMS to reduce fingerprinting=
.</div><div><br></div><div>&gt; Many inputs with different internal keys ca=
n be combined to satisfy the</div>total output value for a single output, a=
s long as their scriptpubkeys<br>with FLU and NUMS internal key are equal T=
his enables avoiding address<br>reuse within the vault.<div><br></div><div>=
To reiterate, we can just cycle any key in the $trigger branch with OP_FLU,=
 which accomplishes the same thing.</div><div>Or in authorization-less $tri=
gger, add a random number which is dropped.</div><div><br></div><div>&gt; M=
any inputs with the same scriptpubkey can be combined to satisfy a</div>sin=
gle CTV output template. This allows a user to unfsck themselves if<br>they=
 initiate a withdrawal that cannot be satisfied because they didn&#39;t<br>=
send enough sats to satisfy their template.<div><br></div><div>I think that=
 would fit the deprecated OP_FORWARD_OUTPUTS, but OP_CTV commits to total</=
div><div>number of inputs to remove txid malleability. I think the real sol=
ution to this mistake would be to hit</div><div>the big red RECOVERY button=
 that you&#39;re relying on for vault security anyways.</div><div><br></div=
><div>Cheers,</div><div>Greg</div></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 13, 2023 at 3:04=E2=80=AFPM B=
randon Black &lt;<a href=3D"mailto:freedom@reardencode.com" target=3D"_blan=
k">freedom@reardencode.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">Hi Gents,<br>
<br>
&gt; &gt; I don&#39;t think replacing the internal-public-key makes sense -=
- if it<br>
&gt; was immediately spendable via the keypath before there&#39;s no reason=
 for<br>
&gt; it not to be immediately spendable now.<br>
&gt; <br>
&gt; Slavishly following the current proposal was the idea to make sure all=
<br>
&gt; functionality was captured; I agree with this change.<br>
<br>
I think we do need to replace the internal key with a hardcoded NUMS<br>
point to allow us to batch multiple vault inputs which might have<br>
different internal keys but the same OP_FLU/OP_VAULT_TRIGGER script to<br>
the same time+template-restricted output.<br>
<br>
I like that in James&#39; current PR proposal we can explicitly batch via<b=
r>
the implied input/output summation rules while avoiding address reuse.<br>
If we can retain some or all of that, I think it would be good for on<br>
chain efficiency and potentially privacy.<br>
<br>
My thoughts on batching:<br>
<br>
Many inputs with different internal keys can be combined to satisfy the<br>
total output value for a single output, as long as their scriptpubkeys<br>
with FLU and NUMS internal key are equal This enables avoiding address<br>
reuse within the vault.<br>
<br>
Many inputs with the same scriptpubkey can be combined to satisfy a<br>
single CTV output template. This allows a user to unfsck themselves if<br>
they initiate a withdrawal that cannot be satisfied because they didn&#39;t=
<br>
send enough sats to satisfy their template.<br>
<br>
Best,<br>
<br>
--Brandon<br>
</blockquote></div>

--00000000000093f42b05f6dd3708--