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 35EE8E37 for ; Sat, 19 Dec 2015 18:42:47 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149081.authsmtp.net (outmail149081.authsmtp.net [62.13.149.81]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 63589159 for ; Sat, 19 Dec 2015 18:42:46 +0000 (UTC) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt23.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBJIgjeU092018 for ; Sat, 19 Dec 2015 18:42:45 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 tBJIgfHQ069562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 19 Dec 2015 18:42:44 GMT Date: Sat, 19 Dec 2015 10:42:40 -0800 From: Peter Todd To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20151219184240.GB12893@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8GpibOaaTibBMecb" Content-Disposition: inline X-Server-Quench: 4aca2f52-a680-11e5-bcde-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktca1U6ClZ1 UkhIR0JTHA9sAxYF AlAcVgd1dhtEe3xu ZEF9W3hcQ0U0MTQH OxkCbQwGY25lbmJR U0NRcU1QIVAbfElA aE0uUnsNfGQGM399 FQQ/MnVpZWwCcXsL SQhUfAIEfktDGDMx S1geGn0hHF1NWyU+ ZxYiLVUfVFkQLkUy Nl8tWFQXexYOFgRV HCkA X-Authentic-SMTP: 61633532353630.1038: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 Subject: [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: Sat, 19 Dec 2015 18:42:47 -0000 --8GpibOaaTibBMecb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable At the recent Scaling Bitcoin conference in Hong Kong we had a chatham house rules workshop session attending by representitives of a super majority of the Bitcoin hashing power. One of the issues raised by the pools present was block withholding attacks, which they said are a real issue for them. In particular, pools are receiving legitimate threats by bad actors threatening to use block withholding attacks against them. Pools offering their services to the general public without anti-privacy Know-Your-Customer have little defense against such attacks, which in turn is a threat to the decentralization of hashing power: without pools only fairly large hashing power installations are profitable as variance is a very real business expense. P2Pool is often brought up as a replacement for pools, but it itself is still relatively vulnerable to block withholding, and in any case has many other vulnerabilities and technical issues that has prevented widespread adoption of P2Pool. Fixing block withholding is relatively simple, but (so far) requires a SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should do this hard-fork in conjunction with any blocksize increase, which will have the desirable side effect of clearly show consent by the entire ecosystem, SPV clients included. Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block witholding attacks are a good thing, as in their model they can be used by small pools against larger pools, disincentivising large pools. However this argument is academic and not applicable to the real world, as a much simpler defense against block withholding attacks is to use anti-privacy KYC and the legal system combined with the variety of withholding detection mechanisms only practical for large pools. Equally, large hashing power installations - a dangerous thing for decentralization - have no block withholding attack vulnerabilities. 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/ --=20 'peter'[:-1]@petertodd.org 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d --8GpibOaaTibBMecb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWdaUdXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMTg4YjYzMjFkYTdmZWFlNjBkNzRjN2IwYmVjYmRhYjNi MWEwYmQ1N2YxMDk0N2QvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udz/CQf/feQGol/cvrOnDt3/YFLhh0ku PnCP3qlKeWULexRMHzKUYmflz5rjg59k2T6lFRENqrQVZa1zTjmP92MlN4IDUqG4 WUuRFfSD36PX8UpkXnBkCCyTGV5OBjxId+BsEPecU49Q2RJ1wYOhA6d1oLUlq+7J Q1j/IpfsjW3eoKoXsVvoMuvHUt2e+FJO4B3bxjoAYJSe+8/VlcGgrJMlKyVJgNZj 2KfD0E4sptKTWbNY7mESBbUhi1jaOG6F4WKbg7zURWkc4jhIn0HbrE4lsmSSns0f wgtRdyWUG7JFkAwev9Wa4H/DZ+AHNUXMAEHxVpjwNxFiiFycx5QG5P0mfilmfw== =JwQ/ -----END PGP SIGNATURE----- --8GpibOaaTibBMecb--