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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 104F12C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 May 2017 06:37:36 +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 smtp1.linuxfoundation.org (Postfix) with ESMTPS id E40AE13D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 May 2017 06:37:34 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian))
id 1dEVLv-0004qK-Eh for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 May 2017 16:37:33 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Sat, 27 May 2017 16:37:26 +1000
Date: Sat, 27 May 2017 16:37:26 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20170527063726.GA12042@erisian.com.au>
References: <D0299438-E848-4696-B323-8D0E810AE491@gmail.com>
<CAFmyj8zNkPj3my3CLzkXdpJ1xkD0GQk8ODg09qYnnj_ONGUtsQ@mail.gmail.com>
<2E6BB6FA-65FF-497F-8AEA-4CC8655BAE69@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2E6BB6FA-65FF-497F-8AEA-4CC8655BAE69@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY,
MONEY_FRAUD_3, RP_MATCHES_RCVD, T_MONEY_PERCENT,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 27 May 2017 12:28:42 +0000
Subject: Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial
mitigation of CVE-2017-9230
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: Sat, 27 May 2017 06:37:36 -0000
On Fri, May 26, 2017 at 11:02:27AM +0300, Cameron Garnham via bitcoin-dev wrote:
> If one assumes that the 67% of the hash rate that refuse to signal
> for SegWit are using ASICBOOST. The entire picture of this political
> stalemate became much more understandable.
A couple of bits of math that might be of interest:
* if 67% of the hash rate is running ASICBoost, and ASICBoost gives a
20% performance improvement as stated on asicboost.com and in
Greg's BIP proposal, then blocking ASICBoost would change the
balance of miners from 67%/33% to 62.8%/37.2%; resulting in a 6.3%
loss for income for ASICBoost miners (not 20%), and a 12.7% gain for
non-ASICBoost miners. In this case, total apparent hashrate reduces
to 88.8% of what it originally was when ASICBoost is blocked (though
the actual security either stays the same or increases, depending on
your attack model) [0]
* if ASICBoost use is lower than that, say 33% (eg made up of
AntPool 18%, BTC.top 10%, ViaBTC 5%), then the shift is from 33%/67%
to 29.1%/70.9%, and results in a 13% loss for ASICBoost miners,
versus a 6% gain for non-ASICBoost miners. In these cases, a price
rise in the region of 7% to 15% due to blocking ASICBoost would be
enough to make everyone better off [1].
* AIUI there are three feasible ways of doing ASICBoost: overt via
the version field, semi-covert via mining an empty block and grinding
the coinbase extra nonce, and fully covert by reordering the block
transaction merkle tree. If the fully covert method is made infeasible
via a secondary merkle commitment in the coinbase a la segwit, and for
whatever reason overt ASICBoost isn't used, then empty block mining is
still plausible, though presumably becomes unprofitable when the extra
20% of block subsidy is less than the fees for a block. That's adds
up to fees per block totalling greater than 2.5BTC, and 2.5BTC/1MB is
250 satoshis per byte, which actually seems to be where fees are these
days, so unless they're getting more than the claimed 20% benefit,
people mining empty blocks are already losing money compared to just
mining normally... (Of course, 250 satoshis per byte is already fairly
painful, and only gets more so as the price rises)
Personally, I expect any technical attempt to block ASICBoost use to fail
or result in a chain split -- 67% of miners losing 6% of income is on
the order of $5M a month at current prices. Having an approach that is as
simple as possible (ie, independent from segwit, carefully targetted, and
impossible to oppose for any reason other than wanting to use ASICBoost)
seems optimal to me, both in that it has the highest chance to succeed,
and provides the most conclusive information if/when it fails.
Cheers,
aj
[0] Assuming ASICBoost miners have hardware capable of doing A hashes with
ASICBoost turned off, or A*B (B=1.2) with ASICBoost turned on, and
the remainder of miners have a total hashrate of R. Then overall
hashrate is currently H=A*B+R, and ASICBoost hashrate is a = A*B/(A*B+R),
with a = 67% if the quoted claim is on the money. Rearranging:
a = A*B/(A*B+R)
a*(A*B+R) = A*B
a*A*B + a*R = A*B
a*R = (1-a)*A*B
R = (1/a-1)*A*B
So a' = A/(A+R), the ASICBoost miner's hashrate if they're forced to
turn ASICBoost off, is:
a' = A/(A+R)
a' = A/(A+(1/a-1)*A*B)
= 1/(1+(1/a-1)*B)
But if a=0.67 and B=1.2, then a' = 0.628.
The ratio of what they are getting to what they would getting is
just a/a',
a/a' = a*(1+(1/a-1)*B)
= (a+(1-a)*B)
and their loss is a/a'-1, which is:
a/a'-1 = (a+(1-a)*B) - 1
= (a+(1-a)*B) - (a+1-a)
= (1-a)*(B-1)
which is only 20% (B-1) when a is almost zero. When a increases (ie,
there is a higher percentage of ASICBoost miners, as sure seems to
be the case) the potential loss from disabling ASICBoost dwindles
to nothing (because 1-a goes to zero and B-1 is just a constant).
Note that this is the case even with mining centralisation -- if you
have 99% of the hashrate with ASICBoost, you'll still have 98.8% of
the hashrate without it, making a 0.2% loss (though of course your
competitors with 1% hashrate will go to 1.2%, making a 20% gain).
The reason is you're competing with all the ASICBoost miners,
*including your own*, for the next block, and the size of the reward
you'll get for winning doesn't change.
Total apparent hashrate is A+R versus A*B+R, so
(A+R)/(A*B+R) = 1/(A/(A+R)) * (A*B/(A*B+R))/B
= 1/a' * a/B
= a/a' / B
= (a+(1-a)*B) / B
= a/B + (1-a)
(yeah, so that formula's kind of obvious...)
[1] Except maybe the patent holders (err, applicants). Though per the
recent open letter it doesn't seem like anyone's actually paying for
the patents in the first place. If miners were, then coordinated
disarmament might already be profitable; if you're paying say 10%
of your mining income in licensing fees or similar, that might seem
sensible in order to make 20% more profit; but if blocking everyone
from using ASICBoost would reduce your licensing fees by 10% of your
income, but only reduce your income by 6.3%, then that adds up to
a 3.7% gain and a bunch less hassle.
I think if the ASICBoost patent holders were able to charge perfectly
optimally, they'd charge royalty fees of about 8.3% of miner's
income (so ASICBoost miners would make 10% net, rather than 20%),
and allow no more than 50% of miners to use it (so the effective
ASICBoost hashrate would be about 55%). That way the decision to
block ASICBoost would be:
X * 1.2 * (1-0.083) / (0.5 * 1.2 + 0.5) -- ASICBoost allowed
= X * 1.1004 / 1.1
> X
vs
X / (0.5 + 0.5) -- ASICBoost banned
= X
and ASICBoost wouldn't be disabled, but the patent holders would
still be receiving 4.15% (50%*8.3%) of all mining income. If more
than 50% of hashpower was boosted, the formula would change to, eg,
X * 1.2 * (1-0.083) / (0.51 * 1.2 + 0.49)
= X * 1.1004 / 1.102
< X
and similarly if the fee was slightly increased, and in that case all
miners would benefit from disabling ASICBoost. Around these figures
ASICBoost miners would only gain/lose very slightly from ASICBoost
getting blocked; the big losers would be the patent holders, who'd
go from raking in 4.15% of all mining income to nothing, and the
big winners would be the non-ASICBoost miners, who'd gain that 4.15%
of income. The possibility of transfer payments from non-ASICBoost
miners to ASICBoost miners to block ASICBoost might change that
equation, probably towards lower fees and higher hashrate.
For comparison, if 67% of hashrate is using ASICBoost, they can't
charge them all more than 5.5% of their mining income, or miners
would prefer to block ASICBoost, and that would only give the patent
holders 3.7% of all mining income, much less.
If patent holders can convince miners not to communicate with each
other so that they think that a smaller amount of hashpower is using
ASICBoost than actually is, that might also allow collecting more
royalties without risking collective action to block ASICBoost.
Of course, this is assuming they can charge all miners optimally
and no one infringes patents, and that if you're prevented from
using ASICBoost you don't have to keep paying royalties anyway,
and so on. Just completely realistic, plausible assumptions like that.
|
