On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn <m...@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. — Because the properties promised by the system can not be upheld if 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— 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— man has survived eons without Bitcoin just fine— and there are many practical reasons 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. ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development