Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

[Eric Voskuil <eric@voskuil.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Anthony,

For the sake of argument:

(1) What would the situation look like if there was no patent?

(2) Would the same essential formulation exist if there had been a
patent on bitcoin mining ASICs in general?

(3) Would an unforeseen future patented mining optimization exhibit
the same characteristics?

(4) Given that patent is a state grant of monopoly privilege, could a
state licensing regime for miners, applied in the same scope as a
patent, but absent any patent, have the same effect?

e

On 05/26/2017 11:37 PM, Anthony Towns via bitcoin-dev wrote:
> 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.
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJZKdyaAAoJEDzYwH8LXOFO83IH/2FNwxjg1x9mlYMCLntShQZ+
2eA3M/0Hg+Zys9JfkHeRfaXr8qIC4inAJ88dDZ8EoVwKlAobmVk9iBEb/+3IS2ol
XKVSloe12AG3z0zi09bDtSu3b49Z11ZCw10uveHKbxxKqaiT1wohgX8eefHox1OJ
iGni8mGZhm3q4XTCtf5DrwTLAyplfHIeYtniXmlgkSpPjujJEB0H8viWs0QmghVc
udQqz5MfcBu1Rf9TukpT+lhOWDw189mTkomNy/npJaiJFalBIIzT6iMIU22FRS6j
xibIgdfq+3zAlZj4YAtyoIXSqdOnN2LKieY2hiLSjXwjk1xjnrqIc4ApDuW+dfk=
=NeOF
-----END PGP SIGNATURE-----