path: root/b8/1960831b216904c835e29474a950ae6f42b44f

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3CE242C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 May 2017 20:07:58 +0000 (UTC)
Received: by mail-pg0-f49.google.com with SMTP id 8so7493195pgc.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <aj@erisian.com.au>, bitcoin-dev@lists.linuxfoundation.org
References: <D0299438-E848-4696-B323-8D0E810AE491@gmail.com>
	<CAFmyj8zNkPj3my3CLzkXdpJ1xkD0GQk8ODg09qYnnj_ONGUtsQ@mail.gmail.com>
	<2E6BB6FA-65FF-497F-8AEA-4CC8655BAE69@gmail.com>
	<20170527063726.GA12042@erisian.com.au>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <f25dee23-4e92-d464-9fec-20d0c54c573b@voskuil.org>
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 <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 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-----