summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAnthony Towns <aj@erisian.com.au>2017-05-27 16:37:26 +1000
committerbitcoindev <bitcoindev@gnusha.org>2017-05-27 06:37:36 +0000
commitaac062c5f8477968341556e16571e408d3eae3d0 (patch)
treed404134e430f608b2097e00448ea55448426986c
parent45cf436bd451bb3f2225f7b7aaa63fbcdeda3607 (diff)
downloadpi-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/e6d137f9e5e9351ddd41f770367862ae1e1da0217
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.
+
+