diff options
| author | Jeremy Rubin <j@rubin.io> | 2022-04-22 00:30:08 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-22 05:36:07 +0000 |
| commit | a08a68da85688f6b1a2b5d4124a049677506c161 (patch) | |
| tree | 7cc3cc25b1ff83292f80faa586c3f5ba9bd584d3 | |
| parent | da4c53b2227da422749cf697430fc2c13a00e358 (diff) | |
| download | pi-bitcoindev-a08a68da85688f6b1a2b5d4124a049677506c161.tar.gz pi-bitcoindev-a08a68da85688f6b1a2b5d4124a049677506c161.zip | |
Re: [bitcoin-dev] CTV Signet Parameters
| -rw-r--r-- | 85/4faf51b3b96ab27d92515d2fffc44f2e8ddd97 | 385 |
1 files changed, 385 insertions, 0 deletions
diff --git a/85/4faf51b3b96ab27d92515d2fffc44f2e8ddd97 b/85/4faf51b3b96ab27d92515d2fffc44f2e8ddd97 new file mode 100644 index 000000000..9fa4faf65 --- /dev/null +++ b/85/4faf51b3b96ab27d92515d2fffc44f2e8ddd97 @@ -0,0 +1,385 @@ +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'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's clear th= +at 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.</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 > 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's also cool to think about how cheapness of the nodes in the gra= +ph changes the optimal graph, which means you can'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 <<a href=3D"mailt= +o:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.= +org</a>> 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> +> I can probably make some show up sometime soon. Note that James' v= +ault uses<br> +> 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> +> think the second use of it (since it's not segwit wrapped) wouldn&= +#39;t be<br> +> broadcastable since it's nonstandard.<br> +<br> +The whole point of testing is so that bugs like "wouldn't be broad= +castable<br> +since it's nonstandard" get fixed. If these things are still in th= +e<br> +"interesting thought experiment" 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> +> One case where you actually use less space is if you have a few differ= +ent<br> +> sets of customers at N different fee priority level. Then, you might n= +eed<br> +> to have N independent batches, or risk overpaying against the customer= +'s<br> +> priority level. Imagine I have 100 tier 1 customers and 1000 tier 2<br= +> +> customers. If I batcher tier 1 with tier 2, to provide tier 1 guarante= +es<br> +> I'd need to pay tier 1 rate for 10x the customers. With CTV, I can= + combine<br> +> my batch into a root and N batch outputs. This eliminates the need for= +<br> +> inputs, signatures, change outputs, etc per batch, and can be slightly= +<br> +> smaller. Since the marginal benefit on that is still pretty small, hav= +ing<br> +> bare CTV improves the margin of byte wise saving.<br> +<br> +Bare CTV only saves bytes when *spending* -- but this is when you'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'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 "[push][32 bytes][op_nop4]= +"<br> +=C2=A0- p2tr: empty scriptSig, witness =3D 33B control block,<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[push][32 bytes][op_nop4]"<br> +<br> +You might get more a benefit from bare ctv if you don't pay all 1100<br= +> +outputs in a single tx when fees go lower; but if so, you're also wasti= +ng<br> +quite a bit more block space in that case due to the intermediate<br> +transactions you'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's easy, which does incline me towards bare CTV; but<b= +r> +the closest thing we have to real user data suggests that nobody's goin= +g<br> +to benefit from that possibility anyway.<br> +<br> +> Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we= +<br> +> couldn't use OP_SUCCESSx there either. segwitv0 might be desired i= +f someone<br> +> has e.g. hardware modules or MPC Threshold Crypto that only support EC= +DSA<br> +> signatures, but still want CTV.<br> +<br> +If you desire new features, then you might have to upgrade old hardware<br> +that can'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-- + |