Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.47 as permitted sender)
	client-ip=209.85.214.47; envelope-from=mh.in.england@gmail.com;
	helo=mail-bk0-f47.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CAAS2fgRfUMYwOE51+eY5QE8nDNV==G1OBRzM1AuHjYmYwTFiow@mail.gmail.com>
References: <CANEZrP3=GdyTe+2=cp-ROOJ8_t=yCqO-7GQ4hA-3aksg46p+ww@mail.gmail.com>
	<CAAS2fgQYV7aR86QOwvqMLpFZ+MAwSOSZvV6XuZdXvqjeYziRng@mail.gmail.com>
	<CANEZrP3ZhNYrgQZT4qOohejs3yhgt0c_kT5zwAUVtPP1Q9f1Zg@mail.gmail.com>
	<CAAS2fgSJhX4974BdWGdyJA13kHg7mTgHadC6UdhdUPu0bDDXFg@mail.gmail.com>
	<CALf2ePw82wt08_G2RtUYEBxorjY1ryZ4r+W7atSzDLYMU+rGGQ@mail.gmail.com>
	<CAAS2fgQewysOG7eOHQxmLup4oLJK=jY=q-_4qTL6yKQ855g3ew@mail.gmail.com>
	<50BEACAB.3070304@gmail.com>
	<CAAS2fgRfUMYwOE51+eY5QE8nDNV==G1OBRzM1AuHjYmYwTFiow@mail.gmail.com>
Date: Wed, 5 Dec 2012 11:43:24 +0100
Message-ID: <CANEZrP2W8BnDOBHJY08Pv9x1sOZ_BS7HHQk60Ysk_yFNH+RM5A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
Precedence: list

>> I was under the impression that "connectedness" was the real metric of
>> concern

I think the real thing we need full nodes for is "sockets" where by
socket I mean "resources needed to serve another node".

Last year we actually ran out of sockets and it took forever for new
nodes to connect because so many existing nodes were full. We don't
want to be in that situation again. So we need full nodes, nobody
disputes that.

The question is, if you have a node on your average desktop machine
that gets switched off at night, has a stupid virus scanner that
insists on checking every database write, has users who go from a bit
of light word processing to watching HD video and expect no stutters
or slowdowns - how valuable is such a node, really? Also has to be
weighed against the risk of eventual user frustration when they
discover Bitcoin is slowing their computer down and go around telling
their friends how much it sucks.

Ultraprune+LevelDB+other optimizations are great. They aren't game
changers for two reasons:

1) Eventually network traffic should increase to use up the additional
performance unlocked by optimizations

2) Users demand instant on not just at first start, but any time they
open their wallet. I don't think it ever makes sense for a regular end
user to have their wallet integrated with a full node because it means
if you get an email saying "oh hey I sent you the money" and you start
your wallet so you can see it/spend it, you still have to wait a while
until it catches up from whenever it was last quit. I've done this a
bunch of times and it really sucks to wait.

The only time it makes sense to have a wallet integrated with a full
node is if that node never shuts down, ie, it's a merchant node.

If a casual user has to be using an SPV wallet all the time no matter
what, then it's not a big leap to simply have both an SPV client and a
full node running in parallel for users who want to support the
network. And how do we recruit such users? Well I've got nothing
against light wallets noticing that the system seems to have high
uptime, external connectivity etc and putting a notice on the screen
asking users to take part. For Windows users you could have a
one-click install that sets up a background service (I think .NET
OneClick makes this possible), so getting a full node is totally easy
and transparent.

Going back to the Tor analogy, whilst I agree with Gregorys arguments
that they aren't quite the same, the Tor guys have wanted to
automatically opt users in to being relays for a while. But the
technical complexity of doing it well is really high. It's still on
their wishlist even though Tor is quite old. A good first base to
reach is simply having accurate recommendations. If users start
complaining that they were asked to run a full node but when they did,
performance suffered unacceptably, then we know we need better
heuristics before automatically opting users in.