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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4F0C6C002C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 18:39:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 2DEA040A6E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 18:39:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=mattcorallo.com
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 4Shsn2C9v5JO
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 18:39:23 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by smtp2.osuosl.org (Postfix) with ESMTPS id DF672400B8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 18:39:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mattcorallo.com; s=1650564063; h=In-Reply-To:From:References:Cc:To:Subject:
From:Subject:To:Cc:Reply-To; bh=WCY5o3kJEzjkU8X9qA58ZvEsPfPHalu0T6cJCVd+b6E=;
b=QVPFEEw3n3sqZjkhc/41rayK+yumqM6MSUvvC/WxdpiQDvpcEbi8ck9itPmSM1NLE7yhpGd3xug
vxPNP9UUpVXcMJiKBMgRLpS9QLGc6XLbFjM276KuseHEKCRuxY9zmWa8s6l3NzyfKjKNRcP9uFRHK
8FClnWR6IMxq4I/aEYBQNkK+mHT4eT5zpnO+q1IJ9R3hp2dXDNDG+mRzNA1cc570tY9IS1vMx+B+C
KtXEuxHuhuBNiaA9Nb01sZ2VKBkPJTdt3FyUDdYlosQglJDGvKGfvnicjBs43M2536nrar/IqIEkV
+PIaeBCzOAQ6JdoXMfxRZApvTUkpbCF2sHyA==;
Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim)
(envelope-from <lf-lists@mattcorallo.com>)
id 1nhbi1-000CPS-M1; Thu, 21 Apr 2022 18:39:17 +0000
Message-ID: <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
Date: Thu, 21 Apr 2022 11:39:17 -0700
MIME-Version: 1.0
Content-Language: en-US
To: "David A. Harding" <dave@dtrt.org>
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
<d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
<4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-DKIM-Note: Keys used to sign are likely public at
https://as397444.net/dkim/mattcorallo.com
X-DKIM-Note: For more info, see https://as397444.net/dkim/
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks,
e.g. for CTV
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: Thu, 21 Apr 2022 18:39:24 -0000
On 4/21/22 11:06 AM, David A. Harding wrote:
> On 21.04.2022 04:58, Matt Corallo wrote:
>> On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
>>> The main criticisms I'm aware of against CTV seem to be along the following lines:
>>>
>>> 1. Usage, either:
>>> a. It won't receive significant real-world usage, or
>>> b. It will be used but we'll end up using something better later
>>> 2. An unused CTV will need to be supported forever, creating extra maintenance
>>> burden, increasing security surface, and making it harder to evaluate later
>>> consensus change proposals due to their interactions with CTV
>>
>> Also "is this even the way we should be going about covenants?"
>
> I consider this to be a version of point 1b above. If we find a better way for going about
> covenants, then we'll activate that and let CTV automatically be retired at the end of its five years.
>
> If you still think your point is separate from point 1b, I would appreciate you helping me understand.
No, its unrelated to whether CTV or any other system gets usage. If we were just concerned with
whether CTV would get usage over or under some other alternative proposal then I could see an
argument for your proposal (though the nontrivial cost of any fork to Bitcoin would make me still
strongly disagree with such a way forward in principle).
Rather, I'm instead concerned with us designing something that is going to be the most flexible and
useful and hopefully private covenents design we can, because that doesn't just get users to use the
change to Bitcoin we paid some nontrivial change-cost to incorporate into the Bitcoin's consensus
rules, but gets the most bang-for-our-buck. There are at least three or four separate covenants
designs that have been posted to this list, and I don't see why we're even remotely talking about a
specific one as something to move forward with at this point.
We don't add things to Bitcoin just to find out whether we can. full stop.
We add things to Bitcoin because (a) there's some demonstrated use-cases and intent to use the
change (which I think we definitely have for covenants, but which only barely, if at all, suggests
favoring one covenant design over any other), (b) because its generally considered aligned with
Bitcoin's design and goals, based on developer and more broad community response and (c) because the
technical folks who have/are wiling to spend time working on the specific design space think the
concrete proposal is the best design we have, and finally (d) because the implementation is
well-reviewed and complete.
I do not see how we can make an argument for any specific covenant under (c) here. We could just as
well be talking about TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use CTV can
probably just as easily use those instead - ie this has nothing to do with "will people use it".
>> the Bitcoin technical community (or at least those interested in
>> working on covenants) doesn't even remotely show any signs of
>> consensus around any concrete proposal,
>
> This is also my assessment: neither CTV nor any other proposal currently has enough support to
> warrant a permanent change to the consensus rules. My question to the list was whether we could use
> a transitory soft fork as a method for collecting real-world usage data about proposals. E.g., a
> consensus change proposal could proceed along the following idealized path:
>
> - Idea (individual or small group)
> - Publication (probably to this list)
> - Draft specification and implementation
> - Riskless testing (integration tests, signet(s), testnet, etc)
> - Money-at-stake testing (availability on a pegged sidechain, an altcoin similar to Bitcoin, or in
> Bitcoin via a transitory soft fork)
> - Permanent consensus change
That all seems fine, except that doing a fork on Bitcoin has very nontrivial cost, both in terms of
ecosystem disruption and possibility that anything goes wrong, not to mention code maintenance
(which we cannot remove the validation code for something ever, really - you still want to be able
to validate the historical chain). Plus, really, I'd love to see "technical community consensus"
somewhere in there - at least its been something that has very roughly appeared for most previous
soft forks, at least among those who have time/willingness to work on the specific design being
proposed.
[other comments snipped because my responses would mostly have been rehashing the first response above].
Matt
|
