path: root/85/4faf51b3b96ab27d92515d2fffc44f2e8ddd97

Return-Path: <j@rubin.io>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6AE8DC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 05:36:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 5386982ACD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 05:36:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id hnQYx6i2Df9o
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 05:36:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 7A1AD82AB9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 05:36:05 +0000 (UTC)
Received: from relay5-d.mail.gandi.net (unknown [IPv6:2001:4b98:dc4:8::225])
 by mslow1.mail.gandi.net (Postfix) with ESMTP id CBFD4C6489
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 05:30:26 +0000 (UTC)
Received: (Authenticated sender: j@rubin.io)
 by mail.gandi.net (Postfix) with ESMTPSA id BB7DE1C0005
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 05:30:20 +0000 (UTC)
Received: by mail-lf1-f43.google.com with SMTP id x17so12334631lfa.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 22:30:20 -0700 (PDT)
X-Gm-Message-State: AOAM530uG0LJp6yokRuUi6rvuMoG1QqYS+38BNPkgTCAy/Sf2sETyW8g
 DKs2RSZH0aGQofWbYfOEBtWIH2cCaw5mw0SmtYc=
X-Google-Smtp-Source: ABdhPJyu6Lig1JGPiiNcGobV2WSDQlEMiuMSGDR9lXh7lDjiXNHKjJaSwekph7S1K97zByQGeieefMzzaHOpuztwhXo=
X-Received: by 2002:a05:6512:3f0c:b0:471:a86d:7b20 with SMTP id
 y12-20020a0565123f0c00b00471a86d7b20mr1968491lfa.346.1650605419913; Thu, 21
 Apr 2022 22:30:19 -0700 (PDT)
MIME-Version: 1.0
References: <cROVGM8-pKj4YzUX0QMipX3pYW6M5ps8HMrpHD9MJDey8cWBUBJSKc9tNeAJ6XOL2WVPWVwfNYI_LIAmJ4A0lLtolVIF-F1Zn2m27boTO-U=@protonmail.com>
 <20220421050351.GA5616@erisian.com.au>
 <CAMZUoKnCzX6yNaMxaG_hZ1=w_Sa7NPZMbHM=oJ8WsB0sLYVcTw@mail.gmail.com>
 <CAD5xwhhB+HmAt=7ySx-zm1MU4pdkYq3gk-ZfMw__ivViQN4hVA@mail.gmail.com>
 <20220422005804.GC5616@erisian.com.au>
In-Reply-To: <20220422005804.GC5616@erisian.com.au>
From: Jeremy Rubin <j@rubin.io>
Date: Fri, 22 Apr 2022 00:30:08 -0500
X-Gmail-Original-Message-ID: <CAD5xwhikgXr_mxEYuKMLbzNcOJi+Koxjf351XDd5Q_CTja96=Q@mail.gmail.com>
Message-ID: <CAD5xwhikgXr_mxEYuKMLbzNcOJi+Koxjf351XDd5Q_CTja96=Q@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b7e5f205dd378545"
X-Mailman-Approved-At: Fri, 22 Apr 2022 07:55:54 +0000
Subject: Re: [bitcoin-dev] CTV Signet Parameters
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, 22 Apr 2022 05:36:07 -0000

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

small note, it's a savings of 34 or 67 bytes *per histogram bucket* to have
bare CTV v.s. v0/v1, so the interesting thing is that by making it cheaper
bytes wise it might enable one to have, for the same byte budget, more
buckets, which would make the feerate savings for the user even greater.
E.g., assume user priorities are exponential, like:

[10, 12, 14, 17, 20, 24, 29, 35, 42, 51]

suppose binning into 4 groups yields:

[10, 12, 14], [17, 20, 24], [29, 35, 42], [51]
then the feerate of each group summarized by the max times bin count is
[14 x 3], [24 x 3], [42 x 3], [51 x 1] =

291

suppose binning into 5 groups yields:

[10, 12], [14, 17], [20, 24], [29, 35], [42, 51]
[12 x 2] [17 x 2] [24 x 2] [35 x 2] [51x2] =

278

so it's clear that bins of 5 yields a discount, and the marginal cost
difference of 5 bins vs 4 can be more than "paid for" by switching to bare
instead of segwit v0.

E.g., 4 segwits = 4*34 additional
5 bares = 1 extra output (34 bytes) + 1 extra input (41 bytes) + extra tx
body (~10 bytes?) = ~2.5 x 34 additional weight

so while in this particular case, the savings mean that 4 would likely be a
better binning than 5 even if bare were available, if you imagine the
groups scaled to more elements under the same distribution would have
eventually the cost (291-278)*S > 2.5*34  make it worth switching the
binning to 5 bins earlier than with would if the bins were more expensive.

Kinda hard to perfectly characterize this type of knock-on effect, but it's
also cool to think about how cheapness of the nodes in the graph changes
the optimal graph, which means you can't just do a simple comparison of how
much is a bigger than b.





On Thu, Apr 21, 2022 at 7:58 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Apr 21, 2022 at 10:05:20AM -0500, Jeremy Rubin via bitcoin-dev
> wrote:
> > I can probably make some show up sometime soon. Note that James' vault
> uses
> > one at the top-level https://github.com/jamesob/simple-ctv-vault, but I
> > think the second use of it (since it's not segwit wrapped) wouldn't be
> > broadcastable since it's nonstandard.
>
> The whole point of testing is so that bugs like "wouldn't be broadcastable
> since it's nonstandard" get fixed. If these things are still in the
> "interesting thought experiment" stage, but nobody but Jeremy is
> interested enough to start making them consistent with the proposed
> consensus and policy rules, it seems very premature to be changing
> consensus or policy rules.
>
> > One case where you actually use less space is if you have a few different
> > sets of customers at N different fee priority level. Then, you might need
> > to have N independent batches, or risk overpaying against the customer's
> > priority level. Imagine I have 100 tier 1 customers and 1000 tier 2
> > customers. If I batcher tier 1 with tier 2, to provide tier 1 guarantees
> > I'd need to pay tier 1 rate for 10x the customers. With CTV, I can
> combine
> > my batch into a root and N batch outputs. This eliminates the need for
> > inputs, signatures, change outputs, etc per batch, and can be slightly
> > smaller. Since the marginal benefit on that is still pretty small, having
> > bare CTV improves the margin of byte wise saving.
>
> Bare CTV only saves bytes when *spending* -- but this is when you're
> creating the 1100 outputs, so an extra 34 or 67 bytes of witness data
> seems fairly immaterial (0.05% extra vbytes?). It doesn't make the small
> commitment tx any smaller.
>
> ie, scriptPubKey looks like:
>  - bare ctv: [push][32 bytes][op_nop4]
>  - p2wsh: [op_0][push][32 bytes]
>  - p2tr: [op_1][push][32 bytes]
>
> while witness data looks like:
>  - bare ctv: empty scriptSig, no witness
>  - pw2sh: empty scriptSig, witness = "[push][32 bytes][op_nop4]"
>  - p2tr: empty scriptSig, witness = 33B control block,
>          "[push][32 bytes][op_nop4]"
>
> You might get more a benefit from bare ctv if you don't pay all 1100
> outputs in a single tx when fees go lower; but if so, you're also wasting
> quite a bit more block space in that case due to the intermediate
> transactions you're introducing, which makes it seem unlikely that
> you care about the extra 9 or 17 vbytes bare CTV would save you per
> intermediate tx...
>
> I admit that I am inclined towards micro-optimising things to save
> those bytes if it's easy, which does incline me towards bare CTV; but
> the closest thing we have to real user data suggests that nobody's going
> to benefit from that possibility anyway.
>
> > Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we
> > couldn't use OP_SUCCESSx there either. segwitv0 might be desired if
> someone
> > has e.g. hardware modules or MPC Threshold Crypto that only support ECDSA
> > signatures, but still want CTV.
>
> If you desire new features, then you might have to upgrade old hardware
> that can't support them.
>
> Otherwise that would be an argument to never use OP_SUCCESSx: someone
> might want to use whatever new feature we might imagine on hardware that
> only supports ECDSA signatures.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">small note, it&#39;s a sa=
vings of 34 or 67 bytes *per histogram bucket* to have bare CTV v.s. v0/v1,=
 so the interesting thing is that by making it cheaper bytes wise it might =
enable one to have, for the same byte budget, more buckets, which would mak=
e the feerate savings for the user even greater. E.g., assume user prioriti=
es=C2=A0are exponential, like:</div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000">[10, 12, 14, 17, 20, 24, 29, 35, 42, 5=
1]<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">suppose binning into 4 groups yields:</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000">[10, 12, 14], [17,=
 20, 24], [29, 35, 42], [51]</div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">then the=
 feerate of each group summarized by the max times bin count is</div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000">[14 x 3], [24 x 3], [42 x 3], [51 x 1] =3D</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
>291</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000">suppose binning into 5 groups yields:</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000">[10, 12], [14, 17], =
[20, 24], [29, 35], [42, 51]</div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">[12 x 2]=
 [17 x 2] [24 x 2] [35 x 2] [51x2] =3D</div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000">278</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000">so it&#39;s clear th=
at bins of 5 yields a discount, and the marginal cost difference of 5 bins =
vs 4 can be more than &quot;paid for&quot; by switching to bare instead of =
segwit v0.</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:#000000">E.g., 4 segwits =3D 4*34 additional</div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:#000000">5 bares =3D 1 extra output (34 bytes)=C2=A0+ 1 extra input =
(41 bytes)=C2=A0+ extra tx body (~10 bytes?) =3D ~2.5 x 34 additional weigh=
t</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000">so while in this particular case, the savings mean that 4 would lik=
ely be a better binning than 5 even if bare were available, if you imagine =
the groups scaled to more elements under the same distribution would have e=
ventually the cost (291-278)*S &gt; 2.5*34 =C2=A0make it worth switching th=
e binning to 5 bins earlier than with would if the bins were more expensive=
.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000">Kinda hard to perfectly characterize this type of knock-on effect, =
but it&#39;s also cool to think about how cheapness of the nodes in the gra=
ph changes the optimal graph, which means you can&#39;t just do a simple co=
mparison of how much is a bigger than b.</div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div></div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu,=
 Apr 21, 2022 at 7:58 PM Anthony Towns via bitcoin-dev &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-l=
eft-color:rgb(204,204,204);padding-left:1ex">On Thu, Apr 21, 2022 at 10:05:=
20AM -0500, Jeremy Rubin via bitcoin-dev wrote:<br>
&gt; I can probably make some show up sometime soon. Note that James&#39; v=
ault uses<br>
&gt; one at the top-level <a href=3D"https://github.com/jamesob/simple-ctv-=
vault" rel=3D"noreferrer" target=3D"_blank">https://github.com/jamesob/simp=
le-ctv-vault</a>, but I<br>
&gt; think the second use of it (since it&#39;s not segwit wrapped) wouldn&=
#39;t be<br>
&gt; broadcastable since it&#39;s nonstandard.<br>
<br>
The whole point of testing is so that bugs like &quot;wouldn&#39;t be broad=
castable<br>
since it&#39;s nonstandard&quot; get fixed. If these things are still in th=
e<br>
&quot;interesting thought experiment&quot; stage, but nobody but Jeremy is<=
br>
interested enough to start making them consistent with the proposed<br>
consensus and policy rules, it seems very premature to be changing<br>
consensus or policy rules.<br>
<br>
&gt; One case where you actually use less space is if you have a few differ=
ent<br>
&gt; sets of customers at N different fee priority level. Then, you might n=
eed<br>
&gt; to have N independent batches, or risk overpaying against the customer=
&#39;s<br>
&gt; priority level. Imagine I have 100 tier 1 customers and 1000 tier 2<br=
>
&gt; customers. If I batcher tier 1 with tier 2, to provide tier 1 guarante=
es<br>
&gt; I&#39;d need to pay tier 1 rate for 10x the customers. With CTV, I can=
 combine<br>
&gt; my batch into a root and N batch outputs. This eliminates the need for=
<br>
&gt; inputs, signatures, change outputs, etc per batch, and can be slightly=
<br>
&gt; smaller. Since the marginal benefit on that is still pretty small, hav=
ing<br>
&gt; bare CTV improves the margin of byte wise saving.<br>
<br>
Bare CTV only saves bytes when *spending* -- but this is when you&#39;re<br=
>
creating the 1100 outputs, so an extra 34 or 67 bytes of witness data<br>
seems fairly immaterial (0.05% extra vbytes?). It doesn&#39;t make the smal=
l<br>
commitment tx any smaller.<br>
<br>
ie, scriptPubKey looks like:<br>
=C2=A0- bare ctv: [push][32 bytes][op_nop4]<br>
=C2=A0- p2wsh: [op_0][push][32 bytes]<br>
=C2=A0- p2tr: [op_1][push][32 bytes]<br>
<br>
while witness data looks like:<br>
=C2=A0- bare ctv: empty scriptSig, no witness<br>
=C2=A0- pw2sh: empty scriptSig, witness =3D &quot;[push][32 bytes][op_nop4]=
&quot;<br>
=C2=A0- p2tr: empty scriptSig, witness =3D 33B control block,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;[push][32 bytes][op_nop4]&quot;<br>
<br>
You might get more a benefit from bare ctv if you don&#39;t pay all 1100<br=
>
outputs in a single tx when fees go lower; but if so, you&#39;re also wasti=
ng<br>
quite a bit more block space in that case due to the intermediate<br>
transactions you&#39;re introducing, which makes it seem unlikely that<br>
you care about the extra 9 or 17 vbytes bare CTV would save you per<br>
intermediate tx...<br>
<br>
I admit that I am inclined towards micro-optimising things to save<br>
those bytes if it&#39;s easy, which does incline me towards bare CTV; but<b=
r>
the closest thing we have to real user data suggests that nobody&#39;s goin=
g<br>
to benefit from that possibility anyway.<br>
<br>
&gt; Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we=
<br>
&gt; couldn&#39;t use OP_SUCCESSx there either. segwitv0 might be desired i=
f someone<br>
&gt; has e.g. hardware modules or MPC Threshold Crypto that only support EC=
DSA<br>
&gt; signatures, but still want CTV.<br>
<br>
If you desire new features, then you might have to upgrade old hardware<br>
that can&#39;t support them.<br>
<br>
Otherwise that would be an argument to never use OP_SUCCESSx: someone<br>
might want to use whatever new feature we might imagine on hardware that<br=
>
only supports ECDSA signatures.<br>
<br>
Cheers,<br>
aj<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>

--000000000000b7e5f205dd378545--