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 1Tfx43-0004lB-3s for bitcoin-development@lists.sourceforge.net; Tue, 04 Dec 2012 18:17:51 +0000 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; Received: from mail-ie0-f181.google.com ([209.85.223.181]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Tfx3z-0008Q5-Pc for bitcoin-development@lists.sourceforge.net; Tue, 04 Dec 2012 18:17:51 +0000 Received: by mail-ie0-f181.google.com with SMTP id 16so6709394iea.26 for ; Tue, 04 Dec 2012 10:17:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.178.8 with SMTP id cu8mr3810085igc.5.1354645062537; Tue, 04 Dec 2012 10:17:42 -0800 (PST) Received: by 10.64.171.73 with HTTP; Tue, 4 Dec 2012 10:17:42 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Dec 2012 13:17:42 -0500 Message-ID: From: Gregory Maxwell To: Mike Hearn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1Tfx3z-0008Q5-Pc Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients 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: Tue, 04 Dec 2012 18:17:51 -0000 On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn 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.