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
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
|
Return-Path: <luke@dashjr.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B6048C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Feb 2021 17:55:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 9D2C24F02D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Feb 2021 17:55:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level:
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=dashjr.org
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 A9tbvYH6niuC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Feb 2021 17:55:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp4.osuosl.org (Postfix) with ESMTP id C41B74EF74
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Feb 2021 17:55:06 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.190.236.214])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 49ED238A009F;
Sat, 27 Feb 2021 17:55:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1614448505; bh=2jJkIFs/7VnMqjmoj9x5GlXrO5iqHdn/3VDQD6K4PTY=;
h=From:To:Subject:Date:References:In-Reply-To;
b=H+l2Xbof+kD0aC0CCMtYbQ3wqA+zQWCvgcnGHyMgOTDlI7b36JWs8xLYGRRjBXFWA
8Ijb5NGAo74ucDGnN2NSVAgxGH+CI8CFuu+X5wA4DzaNt8AdEiDBH6Mi/t+IKLEsy0
NU1WAqf8tDr4ckrGBllBoiEdGLqaE9l4RTxOVUCg=
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Gregorio Guidi <greg_g@posteo.net>
Date: Sat, 27 Feb 2021 17:55:00 +0000
User-Agent: KMail/1.9.10
References: <bc69d684-3d6e-624e-a859-c2ef8ad5cb13@posteo.net>
In-Reply-To: <bc69d684-3d6e-624e-a859-c2ef8ad5cb13@posteo.net>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202102271755.02271.luke@dashjr.org>
Subject: Re: [bitcoin-dev] Exploring alternative activation mechanisms:
decreasing threshold
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: Sat, 27 Feb 2021 17:55:08 -0000
This has the same problems BIP149 did: since there is no signalling, it is
ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF
nodes will remain on the same chain, with conflicting perceptions of the
rules, and resolution (if ever) will be chaotic. Absent resolution, however,
there is a strong incentive not to rely on the rules, and thus it may never
get used, and therefore also never resolved.
Additionally, it loses the flexibility of BIP 8 to, after the initial
deployment, move the timeoutheight sooner.
Luke
On Thursday 25 February 2021 22:33:25 Gregorio Guidi via bitcoin-dev wrote:
> Hello,
>
> I followed the debate on LOT=false / LOT=true trying to get a grasp of
> the balance of risks and advantages. The summary by Aaron van Wirdum [1]
> explains well the difficulties to find a good equilibrium... it
> concludes that "perhaps, a new possibility will present itself".
>
> Thinking about such a "new possibility" that overcomes the
> LOT=true/false dichotomy, I would like to offer the following proposal.
> It could be called "decreasing threshold activation".
>
> Decreasing threshold activation works similarly to BIP8, with the
> difference that the threshold that triggers the STARTED -> LOCKED_IN
> transition starts at 100% for the first retargeting period, and then is
> gradually reduced on each period in steps of 24 blocks (~1,2%). More
> precisely:
>
> On the 1st period (starting on start_height): if 2016 out of 2016 blocks
> signal, the state is changed to LOCKED_IN on the next period (otherwise
> stays STARTED)
> On the 2nd period: if 1992 out of 2016 blocks signal (~98.8%), the state
> transitions to LOCKED_IN on the next period
> On the 3rd period: if 1968 out of 2016 blocks signal (~97.6%), the state
> transitions to LOCKED_IN on the next period
> ...
> On the 14th period (~6 months): if 1704 out of 2016 blocks signal
> (~84.5%), the state transitions to LOCKED_IN on the next period
> ...
> On the 27th period (~12 months): if 1392 out of 2016 blocks signal
> (~69.0%), the state transitions to LOCKED_IN on the next period
> ...
> On the 40th period (~18 months): if 1080 out of 2016 blocks signal
> (~53.6%), the state transitions to LOCKED_IN on the next period
> ...
> On the 53th period (~24 months): if 768 out of 2016 blocks signal
> (~38.1%), the state transitions to LOCKED_IN on the next period
> ...
> On the 66th period (~30 months): if 456 out of 2016 blocks signal
> (~22.6%), the state transitions to LOCKED_IN on the next period
> ...
> On the 79th period (~36 months): if 144 out of 2016 blocks signal
> (~7.1%), the state transitions to LOCKED_IN on the next period
> ...
> On the 84th and final period (~39 months): if 24 out of 2016 blocks
> signal (~1.2%), the state transitions to LOCKED_IN on the next period,
> otherwise goes to FAILED
>
> (For reference, I include below a snippet of pseudocode for the
> decreasing thresholds in the style of BIP8 and BIP9.)
>
> Here are the main features and advantages of this approach:
>
> 1. It is relatively conservative at the beginning: for activation to
> happen in the first year, it requires a clear majority of signaling
> hashrate, indicating that the activation is relatively safe. Only later
> the threshold starts to move towards "unsafe" territory, accepting the
> tradeoff of less support from existing hashrate in exchange for ensuring
> that the activation eventually happens.
>
> 2. Like LOT=true, the activation will always occur in the end (except in
> the negligible case where less than 1.2% of hashrate supports it).
>
> 3. This approach is quite easy to implement, in particular it avoids the
> extra code to deal with the MUST_SIGNAL period.
>
> 4. There are no parameters to set (except startheight). I am a KISS fan,
> so this is a plus for me, making the activation mechanism robust and
> predictable with less chance for users to shoot themselves in the foot.
> It is also a plus for me that - if adopted as the default mechanism - it
> would require very little discussion on how to activate future
> soft-forks. In fact I think it would be a winning move for Core to
> commit to such a scheme, to avoid getting lost in game-theoretic rabbit
> holes.
>
> 5. Since there is no MUST_SIGNAL period, no automatic chain split occurs
> around activation when not all miners have upgraded (so activation is
> generally as benign as a MASF). A chain split will occur only when/if an
> invalid block is created (and this requires dedicated effort! it can
> only happen by circumventing the normal policy rules [2]). This
> mitigates the risk of reorgs and involuntary forks around activation,
> even with low miner signaling.
>
> 6. It removes motivation to create UASF clients that force activation.
> While individual nodes could still try to force a quicker activation,
> the motivation to do so is reduced since the same result is obtained
> just by waiting a little more.
>
> 7. Compared to LOT=true, activation is cleaner and quicker when it is
> relatively safe to do so (when the signaling hashrate is - let's say -
> in the 70%-80% range). On the other hand, activation is pushed further
> and further in time when it is less safe (when signaling hashrate is
> <50%, meaning that there is a serious risk that users/miners that did
> not upgrade start following an alternative chain). This gives everyone
> time to prepare properly for such a potentially disruptive event.
>
> 8. If a significant number of users and miners consciously decide (for
> whatever reasons) that they don't want to upgrade and want to fork
> themselves off from the chain followed by Core (as is their
> prerogative), they will have time to do so safely.
>
> 9. Compared to the strategy of doing LOT=false and then LOT=true if it
> fails, using the decreasing threshold approach may not seem very
> different. But it completely removes the need to fiddle with different
> client releases and with the issues associated with deployed nodes with
> different consensus parameters.
>
> All in all, reading the various perspectives on this mailing list and
> outside I have the feeling that the strongest arguments against LOT=true
> have at their core a certain uneasiness with the MUST_SIGNAL mechanism
> and the related automatic chain split on activation, which is something
> that greatly complicates the analysis (but please tell me if I am
> wrong...). In this sense, this proposal achieves the big objective of
> always ending in activation (like LOT=true) without resorting to
> MUST_SIGNAL and chain splits.
>
> A final note: this proposal should be seen as somewhat independent from
> the discussion on taproot activation. Personally I would be happy with a
> LOT=false activation for taproot that succeeds quickly, while the
> decreasing threshold approach could be evaluated as potential default
> activation mechanism for the future.
>
> I would be happy to hear what you think about this. What are the
> possible issues/drawbacks of using this mechanism?
>
> Thanks,
>
> Gregorio
>
> [1]
> https://bitcoinmagazine.com/articles/lottrue-or-lotfalse-this-is-the-last-h
>urdle-before-taproot-activation
>
> [2] This was not the case in the past for upgrades such as BIP16 (P2SH),
> which generated frequent reorgs due to a combination of low activation
> threshold (55%) and no policy protection. But for upgrades such as
> taproot the normal policy rules prevent the creation of invalid blocks
> by non-upgraded miners. See
> https://blog.bitmex.com/the-arts-of-making-softforks-protection-by-policy-r
>ule/
>
> Pseudocode:
>
> case STARTED:
> int elapsed_periods = (block.height - startheight) / 2016;
> if (elapsed_periods > 2016 / 24) {
> return FAILED;
> }
> int threshold = 2016 - 24 * (elapsed_periods - 1);
> int count = 0;
> walk = block;
> for (i = 0; i < 2016; i++) {
> walk = walk.parent;
> if (walk.nVersion & 0xE0000000 == 0x20000000 &&
> (walk.nVersion >> bit) & 1 == 1) { ++count;
> }
> }
> if (count >= threshold) {
> return LOCKED_IN;
> }
> return STARTED;
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
