path: root/9e/13856c1a0b1bbf039140222eeda29e8261061d

Return-Path: <nadav@shesek.info>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DB196C007A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 01:10:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id B550382E29
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 01:10:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level: 
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=neutral
 reason="invalid (public key: not available)" header.d=shesek.info
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 wfGhAe9x-yM7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 01:10:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com
 [IPv6:2607:f8b0:4864:20::d35])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 9B5AE82998
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Apr 2022 01:10:37 +0000 (UTC)
Received: by mail-io1-xd35.google.com with SMTP id n134so7160510iod.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 18:10:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shesek.info; s=shesek;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=XW6RgdtGgS6VHjo+nBQirlzLEBU4Ebdne+m4VxtniOY=;
 b=ZTm7VanZDA0JoC/zbZY8dgwOayYWtH7+WUfN4IqkwSTk3Vh11+uz7m67ujZkTzaS6k
 Thm1vatdwfw7V9EvYePZORVj7Xya4N6KzIlAnev3fG1KOLVlfZiZzWUcXCr2IPKbeJoO
 S5/O8DXqZWObU5Ur3uHY77aoN4Ft9HyV2VapQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=XW6RgdtGgS6VHjo+nBQirlzLEBU4Ebdne+m4VxtniOY=;
 b=eAAYzFuhmWRD01slW36rJXSilaTGbuEwwJyuvXzNz3X2t4Y9x7DGSuKteoiAHjatWZ
 sAvtFWk6o65OooahfamTwxKyTEKibMG76LUdqB+sTOdGViIN1LSl+ihZ/Y2/3HiYGnZm
 bk/kdpQ8lnvrovzlKghBWC3BZRg1C495GxDGeGfTedHHHxdOx/AY5mNVQjq06SfbfkeS
 cwvpFybKTsrk+Vjj+UgtM9BjGauBOuwHZiLQfPSKb2hmtAcg9dtTjFspV5eREpIIZ/vd
 JhWQ0y+n+bn9+qYiBJZyxQDX773J8ozabFal7XyVEgjG16EUA3G07PsouxZ627vWVXPq
 YPpw==
X-Gm-Message-State: AOAM531cQtKJHqzRd+VTx2a49NPvKHJMMctHxvXyzq0xZQC6hcZvrqvd
 zhlfKkB3JxWteiXTnZJNVLJZO9rRYKbU1CLU6L5VldjQdm0j6djd
X-Google-Smtp-Source: ABdhPJz9DnynGFu7VlLRoYDbPprhrxl1ZNjzIa+mGpx+j3kfG9oX+HC+nNOp4Np5wv4b2lasx9gKjYF5PyWG9K5cxhI=
X-Received: by 2002:a05:6602:482:b0:614:b990:28c9 with SMTP id
 y2-20020a056602048200b00614b99028c9mr1045143iov.6.1650589836474; Thu, 21 Apr
 2022 18:10:36 -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: Nadav Ivgi <nadav@shesek.info>
Date: Fri, 22 Apr 2022 04:10:25 +0300
Message-ID: <CAGXD5f1hUE_CzV5YGa4wN1w75QbaPYdVaBPiFYjarEiCyNGYsw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000df8d4705dd33e436"
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 01:10:39 -0000

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

> nobody's going to benefit from that possibility anyway.

 James O'Beirne's simple-ctv-vault appears to be using bare CTV outputs:

https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L217-L218
https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L324-L325

I guess this suggests that it was not tested on signet?

On Fri, Apr 22, 2022 at 3:58 AM 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
>

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

<div dir=3D"ltr"><div>&gt; nobody&#39;s going to benefit from that possibil=
ity anyway.<span class=3D"gmail-im"><br></span></div><div><br></div><div>=
=C2=A0James O&#39;Beirne&#39;s simple-ctv-vault appears to be using bare CT=
V outputs:</div><div><br></div><div style=3D"margin-left:40px"><a href=3D"h=
ttps://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b3=
02c65d1b24937/main.py#L217-L218">https://github.com/jamesob/simple-ctv-vaul=
t/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L217-L218</a></div>=
<div style=3D"margin-left:40px"><a href=3D"https://github.com/jamesob/simpl=
e-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L324-L325=
">https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb7=
9b302c65d1b24937/main.py#L324-L325</a></div><div style=3D"margin-left:40px"=
><br></div>I guess this suggests that it was not tested on signet?<br><div>=
<div><span class=3D"gmail-im"></span><div><span class=3D"gmail-im"></span><=
/div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Fri, Apr 22, 2022 at 3:58 AM Anthony Towns via bitcoin-=
dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid 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>

--000000000000df8d4705dd33e436--