From: Nadav Ivgi <nadav@shesek.info>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CTV Signet Parameters
Date: Fri, 22 Apr 2022 04:10:25 +0300 [thread overview]
Message-ID: <CAGXD5f1hUE_CzV5YGa4wN1w75QbaPYdVaBPiFYjarEiCyNGYsw@mail.gmail.com> (raw)
In-Reply-To: <20220422005804.GC5616@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 4037 bytes --]
> 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
>
[-- Attachment #2: Type: text/html, Size: 5541 bytes --]
next prev parent reply other threads:[~2022-04-22 1:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-20 17:13 [bitcoin-dev] CTV Signet Parameters Buck O Perley
2022-04-21 5:03 ` Anthony Towns
2022-04-21 6:16 ` Jeremy Rubin
2022-04-21 6:25 ` Jeremy Rubin
2022-04-21 13:22 ` Russell O'Connor
2022-04-21 15:05 ` Jeremy Rubin
2022-04-22 0:58 ` Anthony Towns
2022-04-22 1:10 ` Nadav Ivgi [this message]
2022-04-22 5:30 ` Jeremy Rubin
-- strict thread matches above, loose matches on Subject: below --
2022-02-17 21:58 Jeremy Rubin
2022-02-18 11:13 ` 0x0ff
2022-02-22 3:19 ` Jeremy Rubin
2022-04-20 2:31 ` Anthony Towns
2022-04-20 17:05 ` Nadav Ivgi
2022-04-21 2:36 ` Anthony Towns
2022-04-28 12:23 ` Jeremy Rubin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGXD5f1hUE_CzV5YGa4wN1w75QbaPYdVaBPiFYjarEiCyNGYsw@mail.gmail.com \
--to=nadav@shesek.info \
--cc=aj@erisian.com.au \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox