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 5FEAB87A for ; Mon, 17 Aug 2015 21:29:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148154.authsmtp.co.uk (outmail148154.authsmtp.co.uk [62.13.148.154]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 21C2B244 for ; Mon, 17 Aug 2015 21:29:20 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7HLTJGP058297; Mon, 17 Aug 2015 22:29:19 +0100 (BST) Received: from muck (S0106e03f49079160.ok.shawcable.net [174.4.1.120]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7HLTDIt018404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 17 Aug 2015 22:29:18 +0100 (BST) Date: Mon, 17 Aug 2015 14:29:12 -0700 From: Peter Todd To: satoshi@vistomail.com Message-ID: <20150817212912.GA15817@muck> References: <6EC9DDF352DC4838AE9B088AB372428A25E1F42A@DS04> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <6EC9DDF352DC4838AE9B088AB372428A25E1F42A@DS04> X-Server-Quench: 04e9ade5-4527-11e5-b398-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwUUGUATAgsB AmMbWVZeUlR7WGo7 ag1VcwFDY1RPXQV1 VUBOXVMcUAIQfXh1 f1oeUxF2dwEIeX51 ZkIsXnQOVRUuIENg RktWEnAHZDJldTIc WUhFdwNWdQpKLx5A PgF4GgpTMjBZIiMm EhR7Izd5JyhZYCpI RgVFK1UeTF1j X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.4.1.120/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: [bitcoin-dev] Incentives to run full nodes 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, 17 Aug 2015 21:29:22 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 15, 2015 at 12:43:54PM -0500, Satoshi Nakamoto via bitcoin-dev = wrote: > They use my old writings to make claims about what Bitcoin was supposed t= o be. However I acknowledge that a lot has changed since that time, and ne= w knowledge has been gained that contradicts some of my early opinions. Fo= r example I didn't anticipate pooled mining and its effects on the security= of the network. Making Bitcoin a competitive monetary system while also p= reserving its security properties is not a trivial problem, and we should t= ake more time to come up with a robust solution. I suspect we need a bette= r incentive for users to run nodes instead of relying solely on altruism. Re: full nodes, my thinking along those lines has been: 1) Incentivising full-nodes is a red herring We can look at this from multiple angles. From the point of view of a wallet, it's not very secure to use Hearn-style SPV mode, and volunteers running full nodes doesn't help things. Sybil attacking the IP address space is pretty easy in comparison to aquiring hashing power sufficient to create false confirmations, so any attacker able to do the former will likely be running the full node you're connecting too anyway. Ultimately, Hearn-style SPV is a close approximation to just trusting anyone with a non-trivial amount of hashing power. (and getting that is surprisingly easy, e.g. w/ SPV mining) =46rom the point of view of full node or miner, having your peers be valiating nodes is at best just a bandwidth optimization; all you need =66rom the rest of the P2P network is flood-fill capability with reasonable DoS resistance. This isn't a problem that strongly requires validation, and if bandwidth needs started to get excessive, sharding the flood-fill network to limit bandwidth of any one flood-fill peer would be relatively easy. 2) The best incentive to validate is clear and immediate failure when you d= on't Currently the game theory and attacks possible against non-validating nodes is a very complex landscape, full of cases where small attacks are infeasible, but larger attacks possible. In particular, in many cases you have co-ordination problems, where an attack is only viable if you can steal at least a block reward worth of Bitcoins to make up for your opportunity cost. This risks lulling people into complacency as attacks seem rare, even if the risk is still quite high as the few attacks that will happen will be very high impact. If the system as a whole made small-scale attacks easier, we wouldn't see this complacency, and people would build stronger systems. A concrete example is Gregory Maxwell's idea of having all blocks commit to two separate merkle trees, one valid and one invalid. Determining which was which would require active validation, and because the block as a whole is still valid regardless, this gives the opportunity to run constant "fire drills" to uncover flaws in validation. Notable, this scheme would even be compatible with SPV clients provided that all sources of invalidity can be proven with a compact fraud proof. A more extreme version of this notion is my embedded consensus ideas, where you rely on the PoW for only proof-of-publication and/or anti-replay functionality. Determining if coins (or any other asset) are real becomes a clear job of validating history yourself, and/or trusting others to do that validation. For instance, my smartcolors colored-coin protocol work implemented client-side validation of colored coins, with a planned (but not fully implemented - client ran out of funds) optimization/trust tradeoff of having the issuer periodically sign merkle-trees committing to all valid proofs within the system on an offline machine. --=20 'peter'[:-1]@petertodd.org 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV0lIlXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzuCwf/YJfiE0SXdXJWttJMBcZ71XJq TOTouzvIpTu8NXPn5v9XUFFvL1OC0g510tVvbb+KDc38LjSWVdMaVsqouMgtcIAj oomhaNjlr0jIu4eRmg9ZWyxtQcmDr6mlpb/gJ98o3TTIc4fzsWM3xAdNC8HmaNpN s98XSheKEOWkkazW6k/QZ7zaQCd27d1877kPloOJ3a8gdfPPk4OZnpxBWEaaapaH 1Z/Z60Jq816LUXtPXRouc9G9PQ038O2vvkBSG162uEGfbuErXYIeSDPUru8bFBpG K5Oh1KrVrU7m8MSD1wGkiSk4wrrw7INarJCU9km12aVd+EAPwsUTMD8a52daww== =Ws7X -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C--