Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CA817BC4 for ; Mon, 13 Jul 2015 16:05:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148096.authsmtp.net (outmail148096.authsmtp.net [62.13.148.96]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 1FF3F14F for ; Mon, 13 Jul 2015 16:05:05 +0000 (UTC) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6DG4xII072582; Mon, 13 Jul 2015 17:04:59 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6DG4raj000369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jul 2015 17:04:56 +0100 (BST) Date: Mon, 13 Jul 2015 12:04:53 -0400 From: Peter Todd To: Jorge =?iso-8859-1?Q?Tim=F3n?= Message-ID: <20150713160453.GB19337@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MW5yreqqjyrRcusr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: e7d47449-2978-11e5-9f75-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwEUEkAYAgsB AmMbWlNeUFl7XGU7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRp1 cRpcA0NydwVFfnc+ ZEBqXXYVCUMucUF5 RkdJF2QBbXphaTUa TUkOcAZJcANIexZF O1F8UScOLwdSbGoL FQ4vNDcwO3BTJTpg Cjo1Exo3QEAKGDF0 XR0cEDwrBgUMDz0p KBYiJ1sVAEcaekQ0 OlYnRVMGPlcTERZD Egcl X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] SPV Mining reveals a problematic incentive issue. 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, 13 Jul 2015 16:05:06 -0000 --MW5yreqqjyrRcusr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 11, 2015 at 11:24:48AM +0200, Jorge Tim=F3n wrote: > All miners should validate transactions precisely because of the latest > attack you've described. Full miners can gain a lot from this attack to > leverage their full validation against spv miners who blindly spend energy > hashing on top of something that may be worthless crap. SPV mining makes = no > sense, but some miners claim they're doind it for very short periods of > time, which shouldn't be as bad as doing it all the time. > > I think it would be more rational for them to keep mining on top of the o= ld > block until they've fully validated the new block (which shouldn't take so > long anyway), even if this slightly increases the orphan rate. You're missing something really critical about what F2Pool/AntPool were (are?) doing: They're finding out about new blocks not by getting block headers from just anywhere, but by connecting to other pools' via stratum anonymously and determining what block hash they're telling the hashers at the pool to work on. (e.g. what prevblockhash is in the block header of shares being generated) If other pools try to fake this information they're immediately and directly losing money, because they're telling their own hashers to make invalid blocks. This of course has a high chance of being detected, and can easily be FUDed into "STOP MINING AT FOO POOL!" reardless of what the ivory tower game theory might say. The only hope the pools have is to somehow identify which connections correspond to other pools with high reliability and target just those connections - good luck on that. Anyway, all this concern about SPV mining is misguided: relying purely on SPV w/ low #'s of confirmations just isn't very smart. What SPV can do - at least while the inflation subsidy is still high - is give reasonable protection against your third-party-run trusted full nodes =66rom lying to you, simply because doing so has well-defined costs in terms of energy to create fake blocks. Targetting enough people at once to make a fake block a worthwhile investment is difficult, particularly when you take into account how timing works in the defenders favor - the attacker probably only has a small % of hashing power, so they're going to wait a long time to find their fake block. Between that and a trusted third party-run full node you're probably reasonably safe, for now. --=20 'peter'[:-1]@petertodd.org 0000000000000000086007e31decd6eb80e07f77271ef50c69e1e6342161f4e5 --MW5yreqqjyrRcusr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVo+GgXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwZjk2ODM1ODVhMzA1MDk1ZDBhYmRjNDNiMGMxN2NlMDVk OGNlYjYxYWU4YjZkZDgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftP0AgAgIrHTnaJBQPGksj+KY8BtQzj xGmpQP4zb7AKWqXIzQFBvxf4YT3wGbxexxG1CUjrACqJG2jND+0P8Ad6A9DFk7oV D9XB/LylX86Gd4rCCFyz9gB22uUkvLHzxcH2D64CoAQOL4NLUyzizlvD+y4WowhG a8meum0ikN7hid8yxPXBdSZZrfgjBTDNN/AuvTqwEu5nx/V8FTI5EePCcZUR1sKD DM760+dFSSqbZtQvSsE+2ra6xkOrBydAgemT8Ow5UNCwtTE3DCEXeP3WhH45QGVW 1YNc+0Pkwug59UAPTua9xKV1W7emhETM18WLIJvDeQ9/I4p6ksZn4mNa8wyKpw== =ArfO -----END PGP SIGNATURE----- --MW5yreqqjyrRcusr--