From: Anthony Towns <aj@erisian•com.au>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
Date: Sat, 27 May 2017 16:37:26 +1000 [thread overview]
Message-ID: <20170527063726.GA12042@erisian.com.au> (raw)
In-Reply-To: <2E6BB6FA-65FF-497F-8AEA-4CC8655BAE69@gmail.com>
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.
next prev parent reply other threads:[~2017-05-27 6:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-26 6:30 Cameron Garnham
2017-05-26 6:52 ` Andreas M. Antonopoulos
2017-05-26 8:02 ` Cameron Garnham
2017-05-26 8:15 ` Eric Voskuil
2017-05-26 19:20 ` Cameron Garnham
2017-05-26 9:21 ` Tom Zander
2017-05-26 14:39 ` Erik Aronesty
2017-05-26 14:54 ` Tom Zander
2017-05-27 6:37 ` Anthony Towns [this message]
2017-05-27 20:07 ` Eric Voskuil
2017-05-29 11:19 ` Anthony Towns
2017-05-31 6:17 ` Eric Voskuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170527063726.GA12042@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox