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 03652721 for ; Wed, 31 May 2017 06:18:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f42.google.com (mail-pg0-f42.google.com [74.125.83.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6435F134 for ; Wed, 31 May 2017 06:18:01 +0000 (UTC) Received: by mail-pg0-f42.google.com with SMTP id u28so3157876pgn.1 for ; Tue, 30 May 2017 23:18:01 -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; bh=xFRemSese1T3cQvlB16guJF9yltDCqIDiS1Yzof/xO4=; b=q0f56V31bkWFSjHT/ulL/xxLsJgrws6r+5WiwWi6bufgCOdt/Bq/aZNhBC7wsz+gl3 fowluYQKnUAx4sCbQnViy5HmTBONFPFbr1HEENl3i2dVtVHm210e81evPZ7ZsXZpeQ14 0xG3TlMi1x+3sLUWUV9X830iePWso/C1msdPutRYjmG099qsfCO7B+ShUMOBELqOEEmX qk0pfWxQE0p+xikH+BRbpI+wiWlwGLIZjdHjHmps940tau0Q7o0KZgIHoXNRT1RGoUdh XJDvAM2JQDquqrJPR9w0ZN/O479mxv+81QAaOkT0gX2pQrBfpOereCVCVv1VeOPWvOYp OYwQ== 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; bh=xFRemSese1T3cQvlB16guJF9yltDCqIDiS1Yzof/xO4=; b=X6yDMiZUj6Wo6HFfrAQkBIinJrl3hKIGaI/ZckURH+wORdwLCHF7nStr0JicOdjrqd LZFc00spK0CqLtAPM5AlVbymB6hoSz8DLn2xYMBa2Bwqc7A7WcYu804hcDKIBMiRPxkC xc1gzs8JWTQEYnFmb2A/jn+psp57pUia927zvkK2mhcIOV8HmJXwW+LQ3oJIHCTnUIow UI06h64/sKkl9uyIm0dRNj+upHz2mMxn/TqbWcJNv8VA1b6ZmFj1qlQEEiQe6l/HviJB nOJaWS6QIM1kuuOeTnTw6WItIR42MgYTwypp1pN3uBc2y7UTDrsYC+FqB9onWsesVH1V jfZw== X-Gm-Message-State: AODbwcAPlcMtIo8X/NWVNFNElZOwz5FWGl8TJvkhLoRba6Hqq5oiUBA1 hzrn9lm6BKdR3YpzjIuezQ== X-Received: by 10.98.204.130 with SMTP id j2mr28350885pfk.107.1496211480894; Tue, 30 May 2017 23:18:00 -0700 (PDT) Received: from ?IPv6:2601:600:a080:16bb:f4b7:8d27:cdfa:1b18? ([2601:600:a080:16bb:f4b7:8d27:cdfa:1b18]) by smtp.gmail.com with ESMTPSA id 204sm22830271pfu.19.2017.05.30.23.17.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 23:18:00 -0700 (PDT) To: Anthony Towns , bitcoin-dev@lists.linuxfoundation.org, Libbitcoin Development References: <2E6BB6FA-65FF-497F-8AEA-4CC8655BAE69@gmail.com> <20170527063726.GA12042@erisian.com.au> <20170529111914.GA21581@erisian.com.au> From: Eric Voskuil Message-ID: Date: Tue, 30 May 2017 23:17:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170529111914.GA21581@erisian.com.au> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aAo2kr7UcK8lv8atWigsPHffC8fK2wr1o" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 31 May 2017 07:04:26 +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: Wed, 31 May 2017 06:18:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aAo2kr7UcK8lv8atWigsPHffC8fK2wr1o Content-Type: multipart/mixed; boundary="E92SqBTcXQCgFsKjsI41uHR1DOlmWlkFW"; protected-headers="v1" From: Eric Voskuil To: Anthony Towns , bitcoin-dev@lists.linuxfoundation.org, Libbitcoin Development Message-ID: Subject: Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230 References: <2E6BB6FA-65FF-497F-8AEA-4CC8655BAE69@gmail.com> <20170527063726.GA12042@erisian.com.au> <20170529111914.GA21581@erisian.com.au> In-Reply-To: <20170529111914.GA21581@erisian.com.au> --E92SqBTcXQCgFsKjsI41uHR1DOlmWlkFW Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/29/2017 04:19 AM, Anthony Towns wrote: > On Sat, May 27, 2017 at 01:07:58PM -0700, Eric Voskuil via bitcoin-dev = wrote: >> Anthony, >> For the sake of argument: >=20 > (That seems like the cue to move any further responses to bitcoin-discu= ss) I didn't meant to imply that the point was academic, just to ask your indulgence before making my point. Thanks for the detailed and thoughtful reply. >> (1) What would the situation look like if there was no patent? >=20 > 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 peri= od > with everyone earning a little less, and then everyone would be back to= > making the same profit. >... I don't accept that the ease (absolute cost) of implementing the ASICBOOST optimization is relevant. The cost of implementation is offset by its returns. Given that people are presumed to be using it profitably I consider this point settled. The important point is that if people widely use the optimization, it does not constitute any risk whatsoever. >> (2) Would the same essential formulation exist if there had been a >> patent on bitcoin mining ASICs in general? >=20 > 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 perfo= rm > comparably to GPUs/FPGAs or whatever everyone else is using. >... I realize that the term "same essential formulation" was misleading, but my aim was the *source* of harm (unblocked) in an ASIC patent as compared to an ASICBOOST patent. It seems that you agree that this harm in both cases results from the patent, not the optimization. Nobody is suggesting that ASICs are a problem despite the significant optimization. It is worth considering an alternate history where ASIC mining had been patented, given that blocking it would not have been an option. More on this below. I agree that the optimizations differ in that there is no known way to block the ASIC advantage, except for all people to use it. But correctly attributing the source of harm is critical to useful threat modeling. As the ASIC example is meant to show, it is very possible that an unblockable patent advantage can arise in the future. >> (3) Would an unforeseen future patented mining optimization exhibit >> the same characteristics? >=20 > 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. Quite clearly then there is a possibility (if not a certainty) that Bitcoin will eventually be faced with an unblockable mining patent advantage. >> (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? >=20 > 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 pu= t > out of business; if you do, you have less profit. There's no way to blo= ck > either via consensus mechanisms, at least in general... Precisely. This is a proper generalization of the threats above. A patent is a state grant of monopoly privilege. The state's agent (patent holder) extracts licensing fees from miners. The state does this for its own perceived benefit (social, economic or otherwise). Extracting money in exchange for permission to use an optimization is a tax on the optimization. > I think it's the case that any optional technology with license fees ca= n't > be made available to all miners on equal terms... This is an important point. Consider also that a subsidy has the same effect as a tax. A disproportionate tax on competing miners amounts to a subsidy. A disproportionate subsidy amounts to a tax on competitors. If the state wants to put its finger on the scale it can do so in either direction. It can compel licensing fees from miners with no need for a patent. It can also subsidize mining via subsidized energy costs (for example), intentionally or otherwise. > Sadly, the solution to this argument is to use discriminatory terms, > either not offering the technology to everyone, or offering varying fee= s > for miners with different hashrates... That sounds more like a central authority than a solution. So, my point: Mis-attributing the threat is not helpful. This is not an issue of an unforeseen bug, security vulnerability, bad miners, or evil patent-holders. This is one narrow example of the general, foreseen, primary threat to Bitcoin - or any hard money. Bitcoin's sole defense is decentralization. People parrot this idea without considering the implication. How does decentralization work? It works by broadly spreading the risk of state attack. But this implies that some people are actually taking the risk. By analogy, BitTorrent is estimated to have 250 million active users in a month, and 200,000 have been sued in the US since 2010. Decentralization works because it reduces risk through risk-sharing. Bitcoin cannot generally prevent state patent/licensing/tax regimes. Licensing is a ban that is lifted in exchange for payment. What is the Bitcoin solution to a global ban on mining? On wallets? On exchange? The Bitcoin defense against a patent is to ignore the patent. Berating people for doing so seems entirely counterproductive. e --E92SqBTcXQCgFsKjsI41uHR1DOlmWlkFW-- --aAo2kr7UcK8lv8atWigsPHffC8fK2wr1o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJZLmAXAAoJEDzYwH8LXOFOUzEH/30lE3qVOOiY0esZ1ytlBY0G Z/hSIwdskUYpvmwL2OMExWHCPaN4qRs7XJShi+1pb4Xr3iVL5BeKx0maEScKX7Qr dyP8xqtuwkpn53lsnCyGGXC1/SYtPddLwbab/ayI1WlAVFx4kyMoNU3oWX9MV0iZ uJ2kVoJFTuZ8LGg/HoZqdGe5aIVJAMHyt+rKC7Z6gfnKTxV/gnRSDXphaVIk92Vd EeHBj8HKPgsjIQclspUeT1JVlNICIVeIqVsZs4j5SSHtmE8TyqUcmgsktYC9Nm8J +NEIFDAGE36/Uli0yGwMZvB6CwW6BY1t9FQwqmf2nW1yEE4MNz5ckG61YjSZIc8= =9HAE -----END PGP SIGNATURE----- --aAo2kr7UcK8lv8atWigsPHffC8fK2wr1o--