From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UZMsY-0007eV-RX for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 14:59:02 +0000 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; Received: from mail-ob0-f179.google.com ([209.85.214.179]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UZMsX-0000WV-Vc for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 14:59:02 +0000 Received: by mail-ob0-f179.google.com with SMTP id xn12so3130312obc.24 for ; Mon, 06 May 2013 07:58:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.47.1 with SMTP id z1mr1091057oem.134.1367852336562; Mon, 06 May 2013 07:58:56 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.167.169 with HTTP; Mon, 6 May 2013 07:58:56 -0700 (PDT) Date: Mon, 6 May 2013 16:58:56 +0200 X-Google-Sender-Auth: FwIKcVxE-MbgN2mw8VvPqPVfI-U Message-ID: From: Mike Hearn To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a11c2103ea051ab04dc0df051 X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UZMsX-0000WV-Vc Cc: Bitcoin Dev Subject: [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 14:59:03 -0000 --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
Subject change to reflect that this is off-topic for the o= ld 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 ge= taddr,
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 n= odes that just connect you back to the sybil. If you seed from DNS then tha= t's your root of trust.

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't OK to spend two minutes trying to connect to lot= s of long-dead IP addresses if you'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'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.

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't pollute your ad= dr-found peers unless it's your first run.

I've actually not experimented with thi= s for a while. I'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're at that stage yet.
--001a11c2103ea051ab04dc0df051--