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 59C96360 for ; Mon, 29 May 2017 11:19:26 +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 76913106 for ; Mon, 29 May 2017 11:19:25 +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 1dFIhl-0004Ze-Lh; Mon, 29 May 2017 21:19:23 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Mon, 29 May 2017 21:19:14 +1000 Date: Mon, 29 May 2017 21:19:14 +1000 From: Anthony Towns To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20170529111914.GA21581@erisian.com.au> References: <2E6BB6FA-65FF-497F-8AEA-4CC8655BAE69@gmail.com> <20170527063726.GA12042@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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,RP_MATCHES_RCVD, 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: Mon, 29 May 2017 12:37:32 +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: Mon, 29 May 2017 11:19:26 -0000 On Sat, May 27, 2017 at 01:07:58PM -0700, Eric Voskuil via bitcoin-dev wrote: > Anthony, > For the sake of argument: (That seems like the cue to move any further responses to bitcoin-discuss) > (1) What would the situation look like if there was no patent? If there were no patent, and it were easy enough to implement it, then everyone would use it. So blocking ASICBoost would decrease everyone's hashrate by the same amount, and you'd just have a single retarget period with everyone earning a little less, and then everyone would be back to making the same profit. But even without a patent, entry costs might be high (redesigning an ASIC, making software that shuffles transactions so you can use the ASIC's features) and how that works out seems hard to analyse... > (2) Would the same essential formulation exist if there had been a > patent on bitcoin mining ASICs in general? Not really; for the formulation to apply you'd have to have some way to block ASIC use via consensus rules, in a way that doesn't just block ASICs completely, but just removes their advantage, ie makes them perform comparably to GPUs/FPGAs or whatever everyone else is using. Reportedly, ASICBoost is an option you can turn on or off on some mining hardware, so this seems valid (I'm assuming not using the option either increases your electricity use by ~20% due to activating extra circuitry, or decreases your hashrate by ~20% and maybe also decreases your electricity use by less than that by not activating some circuitry); but "being an ASIC" isn't something you can turn off and on in that manner. > (3) Would an unforeseen future patented mining optimization exhibit > the same characteristics? Maybe? It depends on whether the optimisation's use (or lack thereof) can be detected (enforced) via consensus rules. If you've got a patent on a 10nm process, and you build a bitcoin ASIC with it, there's no way to stop you via consensus rules that I can think of. > (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? I don't think that scenario's any different from charging miners income tax, is it? If you don't pay the licensing fee / income tax, you get put out of business; if you do, you have less profit. There's no way to block either via consensus mechanisms, at least in general... I think it's the case that any optional technology with license fees can't be made available to all miners on equal terms, though, provided there is any way for it to be blocked via consensus mechanisms. If it were, the choice would be: my percentage of the hashrate is h (0(r-X)*h provided X>0, so all miners are better off if the technology is not allowed (because they all suffer equally in loss of hashrate, which is cancelled out in a retarget period; and they all benefit equally by not having to pay licensing fees). Sadly, the solution to this argument is to use discriminatory terms, either not offering the technology to everyone, or offering varying fees for miners with different hashrates. Unless somehow it works to make it more expensive for higher hashrate miners, this makes decentralisation worse. Cheers, aj