Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.181 as permitted sender)
	client-ip=209.85.223.181; envelope-from=gmaxwell@gmail.com;
	helo=mail-ie0-f181.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP3=GdyTe+2=cp-ROOJ8_t=yCqO-7GQ4hA-3aksg46p+ww@mail.gmail.com>
References: <CANEZrP3=GdyTe+2=cp-ROOJ8_t=yCqO-7GQ4hA-3aksg46p+ww@mail.gmail.com>
Date: Tue, 4 Dec 2012 13:17:42 -0500
Message-ID: <CAAS2fgQYV7aR86QOwvqMLpFZ+MAwSOSZvV6XuZdXvqjeYziRng@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
Precedence: list

On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn <mike@plan99.net> wrote:
> The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
> not convinced this is the best use of time, but if somebody steps up
> to do it, that could also work.

I strongly believe that if community leads with client software which
is not a full _capable_ node (e.g. which can begin life as a SPV node
but at least eventually become full if the system resources permit)
then Bitcoin will fail, or at least fail to be anything but the
world's most inefficient centralized payment system.  Obviously SPV
nodes are excellent tools for getting bitcoin into less capable
systems, but they aren't a general replacement for the software the
participants in Bitcoin run.

=E2=80=94 Because the properties promised by the system can not be upheld i=
f
there is only a fairly small number of self selecting nodes enforcing
the rules. If we wanted a system where its security against theft,
denial of service, and non-inflation were governed by the consensus of
{mtgox,blockchain.info, deepbit, bitpay, slush, btcguild, bitminter}
we could have something infinitely more scalable by just using
something OT like with a simple O(N) consensus between these parties.
No disrespect intended to any of these services=E2=80=94 but a system whos
rules were only enforced at the good graces of a small number of
interested parties is not what the users of bitcoin signed up for.

People obviously care about supporting the goals and security of a the
system they use but actions speak louder than words.  If a
non-validating node is promoted then we're telling people that it's
not important that many people run them.  If running a full node
requires using different software (with a different interface) or a
much more painful initialization than another promoted option then it
will be correctly perceived as costly. If people perceive it to be
both costly and not important then rational participants will not run
it. The result will be fragile to non-existent security, where
dishonest or exploitative parties benefit from running all the full
nodes until they start ripping people off and shift the equilibrium
just a little towards running costly nodes.

It sounds to me that you're insisting that you're asking people who
oppose degrading our recommendations to commit to a costly rushed
development timeline. I think this is a false choice.

There is no set timeline for the adoption of Bitcoin=E2=80=94 man has survi=
ved
eons without Bitcoin just fine=E2=80=94 and there are many practical reason=
s
why slow adoption is beneficial, including reducing the harm users
experience from growing pains.  By allowing things to mature at their
own pace we can preserve the principles that make the system valuable.

If the new user experience is sufficiently bad (and I agree it's bad,
esp with the current release versions of Bitcoin-Qt) then that should
justify more support of work that improves it without compromising the
system. If it's not bad enough to apply those resources, then it's not
bad enough to justify compromising it: as this sort of change is hard
to reverse.