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
|
Return-Path: <thomasv@electrum.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E745987A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 12:03:05 +0000 (UTC)
X-Greylist: delayed 00:20:05 by SQLgrey-1.7.6
Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0B6C91D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 12:03:04 +0000 (UTC)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net
[217.70.183.194])
by slow1-d.mail.gandi.net (Postfix) with ESMTP id B9C374F6736
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 13:36:40 +0200 (CEST)
Received: from mfilter43-d.gandi.net (mfilter43-d.gandi.net [217.70.178.174])
by relay2-d.mail.gandi.net (Postfix) with ESMTP id 7AB33C5A63
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 13:36:37 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter43-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194])
by mfilter43-d.gandi.net (mfilter43-d.gandi.net [::ffff:10.0.15.180])
(amavisd-new, port 10024) with ESMTP id n0Ce0Gs_52TJ
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 13:36:35 +0200 (CEST)
X-Originating-IP: 134.60.149.33
Received: from [134.60.149.33] (wlan149-033.wlan.uni-ulm.de [134.60.149.33])
(Authenticated sender: thomasv@electrum.org)
by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id AE0BAC5A7F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 13:36:35 +0200 (CEST)
To: bitcoin-dev@lists.linuxfoundation.org
From: Thomas Voegtlin <thomasv@electrum.org>
Message-ID: <0a38c993-9269-efb5-7790-e49cd4f7987f@electrum.org>
Date: Thu, 13 Apr 2017 13:36:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Proposal: Soft Fork Threshold Signaling
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Thu, 13 Apr 2017 12:03:06 -0000
Disclaimer: I am fully supportive of Segregated Witness and its
activation by users through BIP148. However, I also believe that a
soft fork would be less risky if it was initially activated by miners,
before the date set in BIP148. This proposal is not intended to
replace UASF, but to mitigate the risks.
The following idea might already have been proposed and discussed
elsewhere. If that is the case, I am sorry for the noise.
Background
==========
BIP9 requires 95% of miner hashrate support in order to activate a
soft-fork. So far, the lack of miner consensus about Segwit has been
frustrating both users and developers. This had led some users to
propose a soft fork activation regardless of the expressed level of
miner support (UASF, BIP148).
There are many risks associated with UASF. If the fork is activated
with less than 50% of the hashing power, the blockchain will have two
competing branches. In addition, if the hashrate on the forking branch
is very low, that branch will be exposed to attacks, where non-empty
blocks are systematically orphaned by adverse miners. This threat may
be a strong deterrent for miners willing to support the fork.
The main argument in favor of UASF is that users, not miners, give its
value to Bitcoin. Therefore, users and markets should have the power
to decide which branch of the fork has the most value, and
profit-driven miners should follow. If the soft-forking branch is
valued more than the non-forking branch, it will end up attracting a
majority of the hashing power, and the non-forking branch will
eventually be orphaned.
Feedback through markets, however, will only work if the forking
branch can effectively be used. If the forking branch is rendered
unusable by adverse miners, there is little chance the new coins will
ever reach markets. To make things worse, profit-driven miners might
adopt a passive attitude and decide to mine on the forking branch only
once a proper price has been set by markets, or only once they see
that it has enough hashing power to be usable. Thus, the lack of
hashrate information prior to the soft fork increases the risk.
On the other hand, if a soft fork was initiated with more than 33% of
the hashing power, then it would probably be viable, because the
remaining two thirds of the hashing power cannot successfully be
allocated to mine blocks on the non-forking branch and to orphan
blocks on the forking branch. Therefore, users will be able to move
coins on the forking branch, and markets will be able to set a price
on these coins, thus creating the feedback needed by profit-driven
miners.
Today about 30% of the hashing power are signaling their intention to
activate Segwit using BIP9. This hashrate is very close to the 33%
threshold, and it would probably be enough to initiate a viable soft
fork; indeed we can expect additional hashing power to be gained from
miners mining on both branches of the fork.
However, nothing suggests that a soft fork triggered with 30% of the
hashrate would be followed by the miners who are currently signaling
Segwit using BIP9. BIP9 signaling means that these miners are willing
to soft fork if support reaches 95%; it does not say anything about
their intentions if support is as low as 30%. In other words, BIP9
signaling does allow miners to properly signal their intentions.
BIP9 signaling
==============
The activation threshold is part of the semantics of BIP9. Miners who
use BIP9 do not only signal their support for a soft fork; they also
signal to other miners that they will activate the soft fork if and
only if support reaches 95%.
Some of these miners might actually be willing to activate a soft fork
with a lower support, even at the cost of creating two chains. Other
miners might not be supportive of that idea, because they consider
that the danger of their blocks being orphaned is too high.
The problem is that this information, at which level of support miners
are willing to initiate a soft fork, is not available. Thus, miners
who are willing to initiate a soft fork at a lower hashrate cannot
coordinate their action.
Proposal: Soft Fork Threshold Signaling
=======================================
Miners signal the threshold at which they are willing to activate a
soft fork. The value of the threshold is published in the coinbase
transaction of the block, with the corresponding version bit.
Miners activate a soft fork if their threshold has been reached over
the last retargeting period. For example, if 504 of 2016 blocks signal
a soft fork with a threshold equal or lower to 25%, then the soft fork
is activated by these miners.
If no activation threshold is reached, the current BIP9 signaling rate
indicator is replaced by a distribution of signaling rates per
threshold. The public availability of threshold information allows
miners to adjust their own threshold, and to optimize their chances of
activating the soft fork.
UASF
====
Even if the soft fork is not activated by miners, this proposal will
reduce the risks associated to a user activated soft fork (UASF). The
public availability of hashrate threshold information prior to the
soft fork will help miners decide whether they should join the fork
right after it has been activated, before price information is
available.
Vulnerabilities
===============
This proposal has similar vulnerabilities as BIP9: it is susceptible
to fake signaling by miners, and to miners withholding hashing power
before the fork.
|
