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 from 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 from 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. > > 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. > > > 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 the > sybil. If you seed from DNS then that's your root of trust. > > The problem with moving away from DNS seeding for bitcoinj clients at least > 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 have > 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. > > 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. > > 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 stable > 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 yet. > ------------------------------------------------------------------------------ > 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 > Bitcoinemail@example.com > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 'peter'[:-1]@petertodd.org 000000000000002a871dc011fe28fd8fbffe577c02b91d2de09aeca8216644ef
Description: Digital signature
------------------------------------------------------------------------------ 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 Bitcoinfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/bitcoin-development