From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3CE242C for ; Sat, 27 May 2017 20:07:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com [74.125.83.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 64293E4 for ; Sat, 27 May 2017 20:07:58 +0000 (UTC) Received: by mail-pg0-f49.google.com with SMTP id 8so7493195pgc.2 for ; Sat, 27 May 2017 13:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=jBhT0WLaBe03syOnid3FrGv5TSbfgslx0D4wlW4GN2E=; b=h5YvTeVQg/0SPSY0LMe6sSaTcIN1dLM7wpQKDUaZDHdN887ZYLFUTTNx+wrWJEIQua rY/MEv43ZwXKvfs27oumJHe3fI4M06kLAChhJ9TqNmgLg2Q9pIXqlHgWdsxBMm9FGFjd hW0AYQQtcljQatwzHzoU4Tt3m+a+MRRrOZETf7munL9CKlg0gUzw2CNvlRZ1WnlwzJTG C+5n736yTUX5mH7iijHCKTXcugnrl44qCjqyK+RE7qcXAti5MKnDb5hdMobymhYvrQ6L prtjd8C9vUU8yr9FDNcqjPH1/e2+GyPueOoIIZ6g4CpDQwriWpRBuIQwk7bJtn5feiyY KmXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jBhT0WLaBe03syOnid3FrGv5TSbfgslx0D4wlW4GN2E=; b=hN1fXftEIWdcMZadfvEogx7HB4qc3iv1PKNEVKZ4dj7p+WkQg+5AN7loQCdPpId6Oq BsecWLnkeWMVt6huwz4YfluQJ4QN1j43K6iaMY9hqllGl/+Wf35hrpm51VS5+69kg6aX iRm4tSQCCtXSxO1bAvsM3KV9W3yVP/hAdz9sk6o8QQofIKk6blCevGOB+f+QopptzMLG bhJkluof/tGJQOB5HETQwpY1A6ap9jb6+668iSt0ItX3L4HotJJoorh2P7ICcil5cTrk e24OAWSUeKBS1Tj66BNygQN128C3m3kUbIGxTOCfHSYYuj/9e/4rgHeUWvN8yO1vnZ9S a0/g== X-Gm-Message-State: AODbwcC5Hgir6evge/r75clIRPlYuTz3BNYQEHeN60Gfnk+ulp0/InRf QcRwuYAYrZt6ow+IC2gDiA== X-Received: by 10.99.127.89 with SMTP id p25mr10044693pgn.92.1495915677473; Sat, 27 May 2017 13:07:57 -0700 (PDT) Received: from ?IPv6:2601:600:a080:16bb:ec0e:d919:7156:50eb? ([2601:600:a080:16bb:ec0e:d919:7156:50eb]) by smtp.gmail.com with ESMTPSA id q9sm7712595pfg.77.2017.05.27.13.07.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 May 2017 13:07:56 -0700 (PDT) To: Anthony Towns , bitcoin-dev@lists.linuxfoundation.org References: <2E6BB6FA-65FF-497F-8AEA-4CC8655BAE69@gmail.com> <20170527063726.GA12042@erisian.com.au> From: Eric Voskuil Message-ID: Date: Sat, 27 May 2017 13:07:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170527063726.GA12042@erisian.com.au> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, LOTS_OF_MONEY, RCVD_IN_DNSWL_NONE, T_MONEY_PERCENT 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 20:15:19 +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 20:07:59 -0000 -----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-----