Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UZO1j-00030T-5S for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 16:12:35 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.108 as permitted sender) client-ip=62.13.148.108; envelope-from=pete@petertodd.org; helo=outmail148108.authsmtp.net; Received: from outmail148108.authsmtp.net ([62.13.148.108]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UZO1h-0004uO-KZ for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 16:12:35 +0000 Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt5.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r46GCQL6046466; Mon, 6 May 2013 17:12:26 +0100 (BST) Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r46GCHrN081318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 6 May 2013 17:12:19 +0100 (BST) Date: Mon, 6 May 2013 12:12:16 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20130506161216.GA5193@petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: ba9631bb-b667-11e2-b10b-0025903375e2 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgQUFVQNAgsB AmUbWlNeUV97W2M7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQxgH cW1mEGdyfwRFeXY+ Z0RqXngVDhVzc0V8 EBxJR2sAYnphaTUd TRJZd1FJcANIexZF aVN4USYPLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMj8n TBccEC8+WkQJSz97 NxUtKVMABw5RLUwp YxMaVEgGMhQfQgdf A1ovSCFePREZXTct AA8SW0kSHSYcKQAA X-Authentic-SMTP: 61633532353630.1019:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1UZO1h-0004uO-KZ Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 16:12:35 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 06, 2013 at 04:58:56PM +0200, Mike Hearn wrote: More generally, I think this shows clearly how SPV nodes have weaker security than constantly operating full nodes, which we knew already, so why not build a better SPV-specific system instead? I've noticed on my Android phone how it often takes quite awhile to find a peer that will actually accept an incoming connection, which isn't surprising really: why should a regular node care about responding to SPV nodes quickly? For fast startup you would be better served with dedicated nodes that are backed by fast hardware and high bandwidth internet connections. You can discourage non-SPV use by refusing to relay full blocks. You can have trusted individuals vouch for these special servers with SSL certificates so you run less of a risk of connecting to a malicious one trying to limit what information you see. For the initial implementation, maybe just make a quick SSL accessible service with HTTP GET so you don't have to integrate SSL into the network protocol and have a couple of these HTTP GETable servers running. (IE, the trust is actually that the SPV seed is honest) Security will be no worse than before - if any one server/seed is honest you're ok - and hopefully better due to the accountability. Obviously you can use the existing bootstrap method in parallel at the same time. What's good about partitioning between SPV and full node bootstrapping, is the regular DNS seeds can optimize the other way: accept that some nodes may turn out to be evil, and limit the damage by returning peers =66rom the widest pool possible even if some of those peers may be a bit slow and unreliable. An attacker can't dominate the results by running a small number of fast reliable nodes because the results returned comes =66rom a huge pool, so they are stuck with getting access to lots of IP addresses, and maybe in the future we'll have even better methods of resisting sybil attacks, and we will be able to implement those methods even if they mean initial bootstrapping is slower. > Subject change to reflect that this is off-topic for the old thread. >=20 > Eventually, I think it makes sense to move to a system where you get seeds > > from > > a DNS (or other mechanism), connect to one or a few of the results, do a > > getaddr, > > fill your peer IP database with it, and disconnect from the DNS seeded > > peer. >=20 >=20 > This obviously makes no difference from a security perspective. If a DNS > seed is compromised it can feed you nodes that just connect you back to t= he > sybil. If you seed from DNS then that's your root of trust. >=20 > The problem with moving away from DNS seeding for bitcoinj clients at lea= st > is that SPV clients are very sensitive to startup time. It isn't OK to > spend two minutes trying to connect to lots of long-dead IP addresses if > you're wanting to pay your bill in a restaurant. That means either you ha= ve > to spin up a lot of TCP connections in parallel, which I know from bitter > experience can cause problems with some crappy wifi routers (they think > it's a synflood), or you get a known fresh source of IPs like a DNS seed > response and then later on bring up connections to the P2P network from > that. >=20 > Implementing the latter is complicated - you have to partition your nodes > so the seed peers are separated from the peers you found via addr > broadcasts and seeded peers can't pollute your addr-found peers unless it= 's > your first run. >=20 > I've actually not experimented with this for a while. I'm hoping that by > the time this gets to the top of my todo list, network nodes will be stab= le > enough that actually you can always obtain at least one or two connections > if you try (say) 30 at once. But I have no idea if we're at that stage ye= t. > -------------------------------------------------------------------------= ----- > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --=20 'peter'[:-1]@petertodd.org 000000000000002a871dc011fe28fd8fbffe577c02b91d2de09aeca8216644ef --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlGH1mAACgkQpEFN739thowmqgCdFPcZhP0EUeQkilyyFLq5b9uh hH0AnAt1Tt8KerZL7uoXBZhCQRYC2f+K =GWNU -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV--