1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id CFDBDC007A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 00:58:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id A5809841C1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 00:58:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=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 DRER5S1X2SIL
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 00:58:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp1.osuosl.org (Postfix) with ESMTPS id 8664B841BE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 00:58:11 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1nhhcd-000533-Ie
for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 22 Apr 2022 10:58:09 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Fri, 22 Apr 2022 10:58:04 +1000
Date: Fri, 22 Apr 2022 10:58:04 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20220422005804.GC5616@erisian.com.au>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAD5xwhhB+HmAt=7ySx-zm1MU4pdkYq3gk-ZfMw__ivViQN4hVA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
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 00:58:12 -0000
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
|
