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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
Return-Path: <luke@dashjr.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id DF127C002F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 21:19:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id D235E400E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 21:19:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level:
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=dashjr.org
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id x0KxKc702QmW
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 21:19:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp2.osuosl.org (Postfix) with ESMTP id B4968400E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 21:19:21 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.151.133.18])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 7673938A1D95
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 21:19:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1642540759; bh=PvgBQ8XxJ0zJ3WXENBP8LhM2crjEp0Yo/kxD6bOpSmI=;
h=From:To:Subject:Date;
b=toDmnjwZvaz/WXhrsXzSEoVG0RXi4RH0I4acXvxudFFyg60z2Sv9oLIziE6ilzFU0
8WvVHxgFAmHm0ZgOa//c4Yu4dcs6MBrs8cwmZxkHyp4VLSLR6DIAbAXpYBvRKSvJNE
KDkAq9UmR2GS6RgWNyyWx2AQiXN/JEZQKNHSYi4w=
X-Hashcash: 1:25:220118:bitcoin-dev@lists.linuxfoundation.org::/TbQNSQJ1ubEFoKc:afsTu
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Tue, 18 Jan 2022 21:19:02 +0000
User-Agent: KMail/1.9.10
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202201182119.02687.luke@dashjr.org>
Subject: [bitcoin-dev] CTV BIP review
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: Tue, 18 Jan 2022 21:19:23 -0000
tl;dr: I don't think CTV is ready yet (but probably close), and in any case
definitely not worth reviving BIP 9 with its known flaws and vulnerability.
My review here is based solely on the BIP, with no outside context (aside from
current consensus rules, of course). In particular, I have _not_ looked at
the CTV code proposed for Bitcoin Core yet.
>Covenants are restrictions on how a coin may be spent beyond key ownership.
nit: Poorly phrased. Even simple scripts can do that already.
>A few examples are described below, which should be the subject of future
non-consensus standardization efforts.
I would ideally like to see fully implemented BIPs for at least one of these
(preferably the claimed CoinJoin improvements) before we move toward
activation.
>Congestion Controlled Transactions
I think this use case hasn't been fully thought through yet. It seems like it
would be desirable for this purpose, to allow any of the recipients to claim
their portion of the payment without footing the fee for every other payment
included in the batch. This is still a covenant-type solution, but one that
BIP 119 cannot support as-is.
(I realise this may be a known and accepted limitation, but I think it should
be addressed in the BIP)
>Payment Channels
Why batch mere channel creation? Seems like the spending transaction should
really be the channel closing.
>CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins than
previously because participants agree on a single output which pays all
participants, which will be lower fee than before.
I don't see how. They still have to agree in advance on the outputs, and the
total fees will logically be higher than not using CTV...?
>Further Each participant doesn't need to know the totality of the outputs
committed to by that output, they only have to verify their own sub-tree will
pay them.
I don't see any way to do this with the provided implementation.
>Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial.
Hard NACK on this. BIP 9 at this point represents developers attempting to
disregard and impose their will over community consensus, as well as an
attempt to force a miner veto backdoor/vulnerability on deployment. It should
never be used again.
Speedy Trial implemented with BIP 8 made sense* as a possible neutral
compromise between LOT=True and LOT=False (which could be deployed prior to
or in parallel), but using BIP 9 would destroy this.
As with Taproot, any future deployments should use BIP 8 again, until a better
solution is developed. Reverting back to a known flawed and vulnerable
activation method should not be done, and it would be better not to deploy
CTV at all at such an expense.
The fact that certain developers attempted to deploy a BIP 9 alternative
activation for Taproot against community consensus, and that even managed to
get released as "Bitcoin Core", makes it all the more important that the
community firmly rejects any further action to force this regression.
* it is my opinion a BIP 8 ST would be an okay compromise under those
circumstances; others do disagree that ST is acceptable at all
> This ensures that for a given known input, the TXIDs can also be known ahead
of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched
Channel Creation constructions as the redemption TXID could be malleated and
pre-signed transactions invalidated, unless the channels are built using an
Eltoo-like protocol.
Why is it a problem for them to use an Eltoo-like protocol?
Why not just commit to the txid itself if that's the goal?
>P2SH is incompatible with CHECKTEMPLATEVERIFY
Maybe the CTV opcode should only be defined/enforced within witness scripts?
>nLockTime should generally be fixed to 0 (in the case of a payment tree, only
the *first* lock time is needed to prevent fee-sniping the root)
Your "Congestion Controlled Transactions" example would only make sense with
the spending transaction much later than the "root", and so could benefit
from fee sniping malleability. (In fact, in that example, it would be better
not to commit to locktime at all.)
>In the CHECKTEMPLATEVERIFY approach, the covenants are severely restricted to
simple templates. The structure of CHECKTEMPLATEVERIFY template is such that
the outputs must be known exactly at the time of construction. Based on a
destructuring argument, it is only possible to create templates which expand
in a finite number of steps.
It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get added.
>For example, a exchange's hot wallet might use an address which can
automatically be moved to a cold storage address after a relative timeout.
Wouldn't it make more sense to just have a UTXO both cold+hot can spend, then
throw away the hot key?
>In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make scripts
valid for policy until the new rule is active.
Policy isn't validity, and cannot be dictated by BIPs (or anyone/anything, for
that matter).
Luke
|
