diff options
author | Anthony Towns <aj@erisian.com.au> | 2017-05-27 16:37:26 +1000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-05-27 06:37:36 +0000 |
commit | aac062c5f8477968341556e16571e408d3eae3d0 (patch) | |
tree | d404134e430f608b2097e00448ea55448426986c | |
parent | 45cf436bd451bb3f2225f7b7aaa63fbcdeda3607 (diff) | |
download | pi-bitcoindev-aac062c5f8477968341556e16571e408d3eae3d0.tar.gz pi-bitcoindev-aac062c5f8477968341556e16571e408d3eae3d0.zip |
Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
-rw-r--r-- | ab/e6d137f9e5e9351ddd41f770367862ae1e1da0 | 217 |
1 files changed, 217 insertions, 0 deletions
diff --git a/ab/e6d137f9e5e9351ddd41f770367862ae1e1da0 b/ab/e6d137f9e5e9351ddd41f770367862ae1e1da0 new file mode 100644 index 000000000..9c2ad2722 --- /dev/null +++ b/ab/e6d137f9e5e9351ddd41f770367862ae1e1da0 @@ -0,0 +1,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. + + |