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 59C96360 for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <aj@erisian.com.au> To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20170529111914.GA21581@erisian.com.au> 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> <f25dee23-4e92-d464-9fec-20d0c54c573b@voskuil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <f25dee23-4e92-d464-9fec-20d0c54c573b@voskuil.org> 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 <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: 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<h, h much less than 1), total hashrate is 1=100%, licensing fee is uniform per hashrate, so h*X, advantage of using technology is a factor of r (0<r, r*h much less than 1) - technology allowed, I use it: I make r*h but pay X*h, so revenue is proportional to (r-X)*h - technology allowed, I don't use it: I make h, pay nothing, so revenue is proportional to h Provides the licensor sets X<r, of these choices I always chose to use the technology, and so does everyone else. So base hashrate if no one were to use the technology is H=1/r. - technology not allowed, no one uses it: I make h blocks, but total hashrate is 1/r, so revenue is proportional to h/(1/r)=rh But rh>(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