Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UZLEx-00082N-Bh for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 13:14:03 +0000 X-ACL-Warn: Received: from vps7135.xlshosting.net ([178.18.90.41]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UZLEw-0005Nn-5B for bitcoin-development@lists.sourceforge.net; Mon, 06 May 2013 13:14:03 +0000 Received: by vps7135.xlshosting.net (Postfix, from userid 1000) id D739233CD49; Mon, 6 May 2013 15:13:55 +0200 (CEST) Date: Mon, 6 May 2013 15:13:55 +0200 From: Pieter Wuille To: Mike Hearn Message-ID: <20130506131353.GA6835@vps7135.xlshosting.net> References: <20130503141801.GA1301@petertodd.org> <20130503151157.GA3902@petertodd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1UZLEw-0005Nn-5B Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] 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 13:14:03 -0000 On Mon, May 06, 2013 at 10:19:35AM +0200, Mike Hearn wrote: > You are welcome to optimise P2P addr broadcasts or develop better bootstrap > mechanisms. I think John's actually has a point here. If we're judging the quality of a protocol change by how compatible it is with DNS seeding, then we're clearly not using DNS seeding as seeding anymore (=getting an entry point into the P2P network), but as a mechanism for choosing (all) peers. 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 probably means we need to look at ways to optimize current peer exchange, but that's certainly welcome in any case. -- Pieter