Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.179 as permitted sender)
	client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f179.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
Date: Mon, 6 May 2013 16:58:56 +0200
Message-ID: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2103ea051ab04dc0df051
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Discovery/addr packets (was: Service bits for
	pruned nodes)
Precedence: list

--001a11c2103ea051ab04dc0df051
Content-Type: text/plain; charset=UTF-8

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.

--001a11c2103ea051ab04dc0df051
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Subject change to reflect that this is off-topic for the o=
ld thread.<div><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">

Eventually, I think it makes sense to move to a system where you get seeds =
from<br>
a DNS (or other mechanism), connect to one or a few of the results, do a ge=
taddr,<br>
fill your peer IP database with it, and disconnect from the DNS seeded peer=
.</blockquote><div><br></div><div style>This obviously makes no difference =
from a security perspective. If a DNS seed is compromised it can feed you n=
odes that just connect you back to the sybil. If you seed from DNS then tha=
t&#39;s your root of trust.</div>
<div style><br></div><div style>The problem with moving away from DNS seedi=
ng for bitcoinj clients at least is that SPV clients are very sensitive to =
startup time. It isn&#39;t OK to spend two minutes trying to connect to lot=
s of long-dead IP addresses if you&#39;re wanting to pay your bill in a res=
taurant. 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&#39;s a synflood), or you get a known fr=
esh source of IPs like a DNS seed response and then later on bring up conne=
ctions to the P2P network from that.</div>
<div style><br></div><div style>Implementing the latter is complicated - yo=
u have to partition your nodes so the seed peers are separated from the pee=
rs you found via addr broadcasts and seeded peers can&#39;t pollute your ad=
dr-found peers unless it&#39;s your first run.</div>
<div style><br></div><div style>I&#39;ve actually not experimented with thi=
s for a while. I&#39;m hoping that by the time this gets to the top of my t=
odo 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 h=
ave no idea if we&#39;re at that stage yet.</div>
</div></div></div></div>

--001a11c2103ea051ab04dc0df051--