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 71524E2A for ; Mon, 28 Dec 2015 20:02:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149112.authsmtp.co.uk (outmail149112.authsmtp.co.uk [62.13.149.112]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3CA10177 for ; Mon, 28 Dec 2015 20:02:28 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBSK2QKF094907; Mon, 28 Dec 2015 20:02:26 GMT Received: from muck (S0106e091f5827ad2.ok.shawcable.net [24.71.232.17]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBSK2LIO015466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Dec 2015 20:02:24 GMT Date: Mon, 28 Dec 2015 12:02:21 -0800 From: Peter Todd To: Emin =?iso-8859-1?B?R/xu?= Sirer Message-ID: <20151228200221.GD12298@muck> References: <20151219184240.GB12893@muck> <219f125cee6ca68fd27016642e38fdf1@xbt.hk> <20151220132842.GA25481@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZmUaFz6apKcXQszQ" Content-Disposition: inline In-Reply-To: X-Server-Quench: ea20f452-ad9d-11e5-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAoUHFAXAgsB AmMbWVReUF97W2Y7 aQ5PagRDYElMQQRt T01BRU1TWkEaYmcD emdhUhh3cwNANn95 bEdqECUKXkQscUN/ Xx8AHDkbZGY1bX0X UkkNagNUcQZLeRZA PlV6Uj1vNG8XDSg5 AwQ0PjZ0MThBHWxq T0kLIF8eCVoMVjA9 V1geHThnF0kCTCZ7 MB06Kl4bGEoQNEp6 OEc9UFkbWwA8 X-Authentic-SMTP: 61633532353630.1037:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.71.232.17/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] We need to fix the block withholding attack X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 20:02:29 -0000 --ZmUaFz6apKcXQszQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 20, 2015 at 12:00:37PM -0500, Emin G=FCn Sirer via bitcoin-dev = wrote: > > In the context of KYC, this techniques would likely hold up in court, > > which means that if this stuff becomes a more serious problem it's > > perfectly viable for large, well-resourced, pools to prevent block > > withholding attacks, in part by removing anonymity of hashing power. > > This would not be a positive development for the ecosystem. > > >=20 > KYC has a particular financial-regulation connotation in Bitcoin circles, > of which I'm sure you're aware, and which you're using as a spectre. > You don't mean government-regulated-KYC a la FINCEN and Bitcoin > exchanges like Coinbase, you are just referring to a pool operator > demanding to know that its customer is not coming from its competitors' > data centers. I mean Knowing Your Customer. The only way to know that a customer is *not* coming from a competitor's data center is to know their identity, which is precisely what KYC is. In the financial world, KYC is used to refer to any time you take steps to determine the real identity/deanonymize your customers. > And your prediction doesn't seem well-motivated or properly justified. > There are tons of conditionals in your prediction, starting with the prem= ise > that every single open pool would implement some notion of identity > checking. I don't believe that will happen. Instead, we will have the big= ger > pools become more suspicious of signing up new hash power, which is a > good thing. And we will have small groups of people who have some reason > for trusting each other (e.g. they know each other from IRC, conferences, > etc) band together into small pools. These are fantastic outcomes for > decentralization. That's a terrible outcomes for decentralization; we *want* people to be able to contribute hashing power to the network even if they don't already have personal connections with existing miners. That's how we attract new players to the mining industry whose backgrounds are not correlated with the backgrounds of other miners - exactly what we want for decentralization. Keep in mind that access to cheap power and cheap opportunities to get rid of waste heat is naturally decentralized by physics, economics, and politics. Basically, the cheapest power, and cheapest ways to get rid of waste heat, is in the form of unique opportunities that don't have economies of scale. For example, much of the Chinese hashing power takes advantage of stranded hydroelectric plants that are located far away =66rom markets that would otherwise buy that power. These plants are limited in size by the local rivers and there's no way to make them any bigger - there's a natural diseconomy of scale involved. Now, support if you have access to such a hydro plant - maybe a mine in the middle of nowhere just closed and there's no-one else to sell the power too. Right now you can buy some hashing equipment(1) and start earning money immediately by pointing it at a pool of your choice. If that pool fucks up, it's really easy for you to change a few lines in your configs and point that hashing power to a different pool. However if block withholding attacks continue and kill off open access pools the process becomes much more arduous. Chances are you won't even bother, and Bitcoin will end up with one less decentralized miner. 1) If access to hashing equipment becomes a limiting factor/fails to improve, Bitcoin itself will likely have to switch PoW functions to succeed as a decentralized system. > Secondly, DRM tech can also easily be used to prevent block withholding > > attacks by attesting to the honest of the hashing power. This is being > > discussed in the industry, and again, this isn't a positive development > > for the ecosystem. > > >=20 > DRM is a terrible application. Once again, I see that you're trying to use > those > three letters as a spectre as well, knowing that most people hate DRM, but > keep in mind that DRM is just an application -- it's like pointing to Ado= be > Flash > to taint all browser plugins. >=20 > The tech behind DRM is called "attestation," and it provides a technical > capability not possible by any other means. In essence, attestation can > ensure that > a remote node is indeed running the code that it purports to be running. > Since > most problems in computer security and distributed systems stem from not > knowing what protocol the attacker is going to follow, attestation is the > only > technology we have that lets us step around this limitation. > > It can ensure, for instance, > - that a node purporting to be Bitcoin Core (vLatest) is indeed running= an > unadulterated, latest version of Bitcoin Core > - that a node claiming that it does not harvest IP addresses from SPV > clients indeed does not harvest IP addresses. > - that a cloud hashing outfit that rented out X terahashes to a user did > indeed rent out X terahashes to that particular user, > - that a miner operating on behalf of some pool P will not misbehave and > discard perfectly good blocks > and so forth. All of these would be great for the ecosystem. Just getting > rid > of the cloudhashing scams would put an end to a lot of heartache. Again, lets look at it from the perspective of someone with access to cheap power. With DRM tech a likely implementation is the equipment manufacturer/pool operator sells you a locked down, tamper-resistant, box that only can send hashing power to a specific pool. 21 for example has been investigating this model. If such equipment is common, even though the guy with a hydro plant in Siberia is physically and politically highly decentralized, the control of the blocks created is highly centralized, rendering his contribution to the network's decentralization moot. At best we might get general purpose attestation, but implementing that vs. locked down, single pool, boxes is more expensive and slower to market. Even then, we'd be much more likely to get fragile and difficult-to-reverse-engineer hashing equipment that's always going to be easier to add backdoors too. We're better off with an ecosystem where DRM tech like attestation isn't needed at all. As for cloud hashing... those scams have mostly died off as the market has become more efficient. > > GHash.io was not a pure pool - they owned and operated a significant > > amount of physical hashing power, and it's not at all clear that their % > > of the network actually went down following that 51% debacle. > > >=20 > Right, it's not clear at all that yelling at people has much effect. As m= uch > fun as I had going to that meeting with GHash in London to ask them to > back down off of the 51% boundary, I am pretty sure that yelling at large > open pools will not scale. We needed better mechanisms for keeping pools > in check. >=20 > And Miner's Dilemma (MD) attacks are clearly quite effective. This is a > time when we should count our blessings, not work actively to render > them inoperable. What evidence do you have for them being "clearly quite effective"? Is there any evidence that they were used against GHash.io for example? Remember that block withholding attacks give an advantage to those with access to large amounts of physical hashing power, like GHash.IO did at that time. > > Basically you have the pool pick a secret k for each share, and commit > > to H(k) in the share. Additionally the share commits to a target divider > > D. The PoW validity rule is then changed from H(block header) < T, to be > > H(block header) < T * D && H(H(block header) + k) < max_int / D > > >=20 > Thanks, this requires a change to the Bitcoin PoW. Good luck with that! It's not a change to the PoW, just a change to the definition of block validity; mining hardware does *not* need to change to implement Luke-Jr's idea. Also, as mentioned elsewhere in this thread, it can be implemented slowly as a pseudo-soft-fork. --=20 'peter'[:-1]@petertodd.org 000000000000000001d3c4acb7446f66482fb6aceb087d7601c9e0644cf60e9a --ZmUaFz6apKcXQszQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWgZVLXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwOTRhZmNiYmFkMTBhYTZjODJkZGQ4YWFkMTAyMDIwZTU1 M2Q1MGE2MGI2YzY3OGYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udy3sQf9G3aF1nJvpv2jr6ovdIZT9XOr EUjGnPSOohT+QbO1AH95b1OIyL1wLrbwZBlBkwNJkPippnmVCimnNYIup80efJjG d17DuABENzGqtrWVUV4xIE+IW1D0U33T9bpaA9Uk8b+reB4FznC0/F+5B8N1Pl/K LwlUDGrZHYXi907ErYtHZkfGzo+sjHiLk34aVDGP/iK7QpVPKTwm6zn0GX+7Ok0X 4NOyTiyr9das3y2h5M7KDJtjIKQGfGTwhTS4vCV7LS5vpQ+NAEZlqOZLuZsa9qDB OcA/jUswmQo1ngzk+Py+ZOI4Pr6ow9xDFYS42jPM3nvJRdHACe5v1zKUfvWvEg== =QHnB -----END PGP SIGNATURE----- --ZmUaFz6apKcXQszQ--