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; 
Date: Mon, 6 May 2013 12:12:16 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20130506161216.GA5193@petertodd.org>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV"
Content-Disposition: inline
In-Reply-To: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
 for pruned nodes)
Precedence: list


--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--