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
|
Return-Path: <aj@erisian.com.au>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 366DBC0733
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jul 2020 09:37:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id DB71D23449
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jul 2020 09:37:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id TnHtlOUTKG5D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jul 2020 09:37:43 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by silver.osuosl.org (Postfix) with ESMTPS id 9BA92204EF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jul 2020 09:37:42 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1jvHNZ-0000wl-1z
for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 14 Jul 2020 19:37:39 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Tue, 14 Jul 2020 19:37:30 +1000
Date: Tue, 14 Jul 2020 19:37:30 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200714093730.myvls2jfpwyi3ap3@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: [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 09:37:46 -0000
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
|
