<div dir="ltr">Subject change to reflect that this is off-topic for the old thread.<div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="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 getaddr,<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 nodes that just connect you back to the sybil. If you seed from DNS then that&#39;s your root of trust.</div>
<div style><br></div><div style>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&#39;t OK to spend two minutes trying to connect to lots of long-dead IP addresses if you&#39;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&#39;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.</div>
<div style><br></div><div style>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&#39;t pollute your addr-found peers unless it&#39;s your first run.</div>
<div style><br></div><div style>I&#39;ve actually not experimented with this for a while. I&#39;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&#39;re at that stage yet.</div>
</div></div></div></div>