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
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id C1CF4C0733
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jul 2020 20:56:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 7210B88905
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jul 2020 20:56:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vKSkjXzB87uN
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jul 2020 20:56:30 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by hemlock.osuosl.org (Postfix) with ESMTPS id 42B5B888C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jul 2020 20:56:30 +0000 (UTC)
Received: from [IPv6:2620:6e:a007:233::100] (unknown
[IPv6:2620:6e:a007:233::100])
by mail.as397444.net (Postfix) with ESMTPSA id BFAB32B171A;
Tue, 14 Jul 2020 20:46:07 +0000 (UTC)
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <20200714093730.myvls2jfpwyi3ap3@erisian.com.au>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <9c401353-d63a-3d19-72a8-ffcaf169ac6d@mattcorallo.com>
Date: Tue, 14 Jul 2020 16:46:06 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20200714093730.myvls2jfpwyi3ap3@erisian.com.au>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Thoughts on soft-fork activation
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, 14 Jul 2020 20:56:35 -0000
Thanks Anthony for this writeup!
I find it incredibly disappointing that the idea of naive flag day fork activation is being seriously discussed in the
form of BIP 9. Activation of forks is not only about the included changes but also around the culture of how changes to
Bitcoin should be and are made. Whether we like it or not, how Taproot activates will set a community understanding and
future norms around how many changes are made.
Members of this list lost sleep and years off their life from stress fighting to ensure that the process by which
Bitcoin changes is not only principled in its rejection of unilateral changes, but also that that idea was broadly
understood, and broadly *enforced* by community members - the only way in which it has any impact. That fight is far
from over - Bitcoin's community grows and changes daily, and the history around what changed and how has been rewritten
time and time again. Worse still, the principled nature of Bitcoin's change process is targeted constantly as untrue in
an attempt by various alternative systems to pretend that their change process of "developers ship new code, users run
it blindly" is identical to Bitcoin.
While members of this list may be aware of significant outreach efforts and design work to ensure that Taproot is not
only broadly acceptable to Bitcoin users, but also has effectively no impact on users who wish not to use it, it is
certainly not the case that all Bitcoin users are aware of that work, nor seen the results directly communicated to them.
Worse still, it is hard to argue that a new version of Bitcoin Core containing a fixed future activation of a new
consensus rule is anything other than "developers have decided on new rules" (even if it is, based on our own knowledge,
not the case). Indeed, even the proposal by Anthony, which makes reference to my previous work has this issue, and it
may not be avoidable - there is very legitimate concern over miners blocking changes to Bitcoin which do not harm them
which users objectively desire, potentially purely through apathy. But to dismiss the concerns over the optics which set
the stage for how future changes are made to Bitcoin purely because miners may be too busy with other things to upgrade
their nodes seems naive at best.
I appreciate the concern over activation timeline given miner apathy, and to some extend Anthony's work here addresses
that with decreasing activation thresholds during the second signaling period, but bikeshedding on timeline may be merited.
To not make every attempt to distance the activation method from the public perception unilateral activation strikes me
as the worst of all possible outcomes for Bitcoin's longevity. Having a quieting period after BIP 9 activation failure
may not be the best way to do that, but it seems like a reasonable attempt.
Matt
On 7/14/20 5:37 AM, Anthony Towns via bitcoin-dev wrote:
> Hi,
>
> I've been trying to figure out a good way to activate soft forks in
> future. I'd like to post some thoughts on that. So:
>
> I think there's two proposals that are roughly plausible. The first is
> Luke's recent update to BIP 8:
>
> https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki
>
> It has the advantage of being about as simple as possible, and (in my
> opinion) is an incremental improvement on how segwit was activated. Its
> main properties are:
>
> - signalling via a version bit
> - state tansitions based on height rather than median time
> - 1 year time frame
> - optional mandatory activation at the end of the year
> - mandatory signalling if mandatory activation occurs
> - if the soft fork activates on the most work chain, nodes don't
> risk falling out of consensus depending on whether they've opted in
> to mandatory activation or not
>
> I think there's some fixable problems with that proposal as it stands
> (mostly already mentioned in the comments in the recently merged PR,
> https://github.com/bitcoin/bips/pull/550 )
>
> The approach I've been working on is based on the more complicated and
> slower method described by Matt on this list back in January. I've got a
> BIP drafted at:
>
> https://github.com/ajtowns/bips/blob/202007-activation-dec-thresh/bip-decthresh.mediawiki
>
> The main difference with the mechanism described in January is that the
> threshold gradually decreases during the secondary period -- it starts at
> 95%, gradually decreases until 50%, then mandatorily activates. The idea
> here is to provide at least some potential reward for miners signalling
> in the secondary phase: if 8% of hashpower had refused to signal for
> a soft-fork, then there would have been no chance of activating until
> the very end of the period. This way, every additional percentage of
> hashpower signalling brings the activation deadline forward.
>
> The main differences between the two proposals is that the BIP 8 approach
> has a relatively short time frame for users to upgrade if we want
> mandatory activation without a supermajority of hashpower enforcing the
> rules; while the "decreasing threshold" approach linked above provides
> quite a long timeline.
>
> In addition, there is always the potential to introduce a BIP 91/148
> style soft-fork after the fact where either miners or users coordinate to
> have mandatory signalling which then activates a pre-existing deployment
> attempt.
>
> I think the design constraints we want are:
>
> * if everyone cooperates and no one objects, we activate pretty quickly
>
> * there's no obvious exploits, and we have plausible contingency plans
> in place to discourage people from try to use the attempt to deploy
> a new soft fork as a way of attacking bitcoin, either via social
> disruption or by preventing bitcoin from improving
>
> * we don't want to ship code that causes people to fall out of
> consensus in the (hopefully unlikely) event that things don't go
> smoothly [0]
>
> In light of that, I think I'm leaning towards:
>
> * use BIP 8 with mandatory activation disabled in bitcoin core -- if
> you want to participate in enforcing mandatory activation, you'll
> need to recompile, or use a fork like bitcoin knots; however if
> mandatory activation occurs on the longest chain, you'll still follow
> that chain and enforce the rules.
>
> * be prepared to update the BIP 8 parameters to allow mandatory
> activation in bitcoin core if, after 9 months say, it's apparent that
> there aren't reasonable objections, there's strong support for
> activation, the vast majority of nodes have already updated to
> enforce the rules upon activation, and there's strong support for
> mandatory activation
>
> * change the dec-threshold proposal to be compatible with BIP 8, and
> keep it maintained so that it can be used if there seems to be
> widespread consensus for activation, but BIP 8 activation does
> not seem certain -- ie, as an extra contingency plan.
>
> * be prepared to support miners coordinating via BIP 91 either to
> bring activation forward in either BIP 8 or "decreasing threshold" or
> de-risk BIP 8 mandatory activation -- ie, an alternative contingency
> plan. This is more appropriate if we've found that users/miners have
> upgraded so that activation is safe; so it's a decision we can make
> later when we have more data, rather than having to make the decision
> early when we don't have enough information to judge whether it's
> safe or not.
>
> * (also, improve BIP 8 a bit more before deploying it -- I'm hoping for
> some modest changes, which is why "decreasing threshold" isn't already
> compatible with BIP 8)
>
> * (continue to ensure the underlying soft fork makes sense and is
> well implemented on its own merits)
>
> * (continue to talk to as many people as we can about the underlying
> changes and make sure people understand what's going on and that
> we've addressed any reasonable objections)
>
> I'm hopeful activating taproot will go smoothly, but I'm not 100% sure
> of it, and there are potentially many different ways in which things go
> wrong; so starting with something simple and being ready to adapt if/when
> we see things starting to go weird seems like a good approach to me.
>
> Cheers,
> aj
>
> [0] At least, that's how I'm phrasing some of the concerns that were
> expressed in, eg,
>
> https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
