MIME-Version: 1.0
In-Reply-To: <20130506161216.GA5193@petertodd.org>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
	<20130506161216.GA5193@petertodd.org>
Date: Mon, 6 May 2013 12:20:12 -0400
Message-ID: <CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
 for pruned nodes)
Precedence: list

On Mon, May 6, 2013 at 12:12 PM, Peter Todd <pete@petertodd.org> wrote:
> 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

Indeed, the DNS seeds are just servers run by trusted individuals anyway.

In either case, bitcoinj definitely wants fixing for its over-reliance
on DNS seeds.  This has been noted as a problem for a while.

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com