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
|
Return-Path: <dave@dtrt.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B2BAEC007A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 01:20:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 8C25040611
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 01:20:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id RpSCE3UFxmXv
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 01:20:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us
[IPv6:2607:fe70:0:3::d])
by smtp4.osuosl.org (Postfix) with ESMTPS id D8882403D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 01:20:17 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id 6133B280004A;
Thu, 21 Apr 2022 18:20:15 -0700 (PDT)
Received: from webmail.rollernet.us (webmail.rollernet.us
[IPv6:2607:fe70:0:14::a])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA;
Thu, 21 Apr 2022 18:20:15 -0700 (PDT)
MIME-Version: 1.0
Date: Thu, 21 Apr 2022 15:20:14 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <01d4a034-eb80-a598-1858-6b0ed8295a13@mattcorallo.com>
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>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <f98a9724da2916e6687771ad1a2b555b@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID d6b.626202cf.198d.0
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 01:20:19 -0000
[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.
> 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.
> Again, my point *is not* "will people use CTV", I think they will. I
> think they would also use TLUV if that were activated for the exact
> same use-cases. I think they would also use CAT+CSFS if that were what
> was activated, again for the exact same use-cases. Given that, I'm not
> sure how your proposal teaches us anything at all, aside from "yes,
> there was demand for *some* kind of covenant".
I'm sorry if my OP was ambiguous about this, but my goal there was to
describe a general framework for activating temporary consensus changes
for the purpose of demonstrating demand for proposed features. I gave
CTV as an example for how the framework could be used, but we could use
the same framework to activate APO and TLUV (or IIDs and EVICT)---and
then we would see which of them people actually used. If there was
significant ongoing use of all three after 5 years, great! We keep them
all. If some of them went largely unused, we let the extra validation
rules expire and move on.
Alternatively, if we only enabled one covenant design (e.g. CTV), we
would still gain data about how it was used and we could see if some of
the alternative designs would've been more optimal for those
demonstrated uses.
My goal here is obtaining data from which we can make informed
decisions. A transitory soft fork is an extreme way to acquire that
data and I fully acknowledge it has several significant problems
(including those I listed in my OP). I'm hoping, though, that it's a
better solution than another activation battle, prolonged yelling on
this mailing list and elsewhere, or everyone just giving up and letting
Bitcoin ossify prematurely. Alternatively, I'm hoping one of the many
people on this list who is smarter than I am will think of another way
to obtain decisive data with less fuss.
> 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.
> You don't
> mention the lack of recursion in CTV vs CAT+CSFS
I mentioned recursion, or the lack thereof, in various proposals like
five times in this thread. :-)
Thanks again for your replies,
-Dave
|
