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
|
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 DF64CC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 18:40:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id BF2E140A6E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 18:40:21 +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 bp-JYvI2XEPw
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 18:40:21 +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 ED9FE405E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 18:40:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mattcorallo.com; s=1650651665; h=In-Reply-To:From:References:Cc:To:Subject:
From:Subject:To:Cc:Reply-To; bh=2BaQKy7vUaxVU6Jbcne99ZFT6olzOC9a2Ce/1hA7L8E=;
b=c0onQJBnEvTRTeQkHN5g/a1FZ8q0vkc7h8piQE7p9D7rRabBXIqtMZOfiyPbwFHYyAOnxLAi2yW
3FcuZekb1qC5rPuwN3LMK/4dgUoXC6jAwftujSxIJ5GQodu0eW63vyJLr8NT6Kb3S0KF3mRjyeL4H
VHaBw9titJ5bM0jPcJM/X3MXgQ8mIZUqnSQcS1yARJ3YehJfzfYWkMw4EfvVRvzUhLVHf1aeyLziP
yQeARFz/oWuEejDDYYhz/ha3wcNSO0Y7k4qrNguyc1eg5bf27iq9SrAHqUh6AUtDscdqe+SF2lmig
U8pZfO67+zbGc8NGLJdr/eu85kBVgHzamJCA==;
Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim)
(envelope-from <lf-lists@mattcorallo.com>)
id 1nhyCY-000RCj-BX; Fri, 22 Apr 2022 18:40:18 +0000
Message-ID: <64ebb176-0243-ac56-3172-b2f4f9b4359f@mattcorallo.com>
Date: Fri, 22 Apr 2022 11:40: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>
<c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
<4056eca7e1ff018bff03918b8c266d76@dtrt.org>
<01d4a034-eb80-a598-1858-6b0ed8295a13@mattcorallo.com>
<f98a9724da2916e6687771ad1a2b555b@dtrt.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <f98a9724da2916e6687771ad1a2b555b@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: Fri, 22 Apr 2022 18:40:22 -0000
On 4/21/22 6:20 PM, David A. Harding wrote:
> [Rearranging Matt's text in my reply so my nitpicks come last.]
>
> On 21.04.2022 13:02, Matt Corallo wrote:
>> I agree, there is no universal best, probably. But is there a concrete
>> listing of a number of use-cases and the different weights of things,
>> plus flexibility especially around forward-looking designs?
>
> I'm sure we could make a nice list of covenant usecases, but I don't know how we would assign
> reasonable objective weights to the different things purely through group foresight. I know I'm
> skeptical about congestion control and enthusiastic about joinpools---but I've talked to developers
> I respect who've had the opposite opinions from me about those things. The best way I know of to
> reconcile our differing opinions is to see what real Bitcoin users actually pay for. But to do
> that, I think they must have a way to use covenants in something like the production environment.
To get good data for this kind of question you'd need much longer than five years, sadly. As we've
seen over and over again in Bitcoin deploying very nontrivial things takes at least five years,
often more. While vaults may be deployed relatively more quickly, the fact that we haven't seen
(AFAIK) *anyone* deploy some of the key-deletion-based vault designs that have been floating around
for some time is indication that even that probably wouldn't be deployed quickly.
>> You're also writing off [...] a community of
>> independent contributors who care about Bitcoin working together to
>> make decisions on what is or isn't the "right way to go" [...]. Why are you
>> suggesting its something that you "don't know how to do"?
>
> You said we should use the best design. I said the different designs optimize for different things,
> so it's unlikely that there's an objective best. That implies to me that we either need to choose a
> winner (yuck) or we need to implement more than one of the designs. In either of those cases,
> choosing what to implement would benefit from data about how much the thing will be used and how
> much users will pay for it in fees.
I agree, there is no objective "best" design. But we can sill explore design tradeoffs and utility
for different classes of covenants. I've seen relatively little of this so far, and from what I have
seen its not been clear that CTV is really a good option, sadly.
>> Again, you're writing off the real and nontrivial risk of doing a fork
>> to begin with.
>
> I agree this risk exists and it isn't my intention to write it off---my OP did say "we [must be]
> absolutely convinced CTV will have no negative effects on the holders or receivers of non-CTV
> coins." I haven't been focusing on this in my replies because I think the other issues we've been
> discussing are more significant. If we were to get everyone to agree to do a transitory soft fork,
> I think the safety concerns related to a CTV soft fork could be mitigated the same way we've
> mitigated them for previous soft forks: heaps of code review/testing and making sure a large part of
> the active community supports the change.
I'm not sure I made my point here clear - the nontrivial and real risk I was referring to was not
avoidable with "moar code review" or "careful analysis to make sure the proposed fork doesn't cause
damage". I mean issues that keep cropping up in many changes like "people start threatening to run a
fork-causing client" or "some miners aren't validating blocks and end up creating a fork" or "some
people forget to upgrade and follow such a fork" or..... there's lots and lots of risks to a doing a
fork that come from the process and nature of forks, that have nothing to do with the actual details
of the fork itself.
Matt
|
