Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 104F12C for ; 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 ; 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 ; 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 To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20170527063726.GA12042@erisian.com.au> References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.