Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of fastmail.co.uk
	designates 66.111.4.28 as permitted sender)
	client-ip=66.111.4.28; envelope-from=jim618@fastmail.co.uk;
	helo=out4-smtp.messagingengine.com; 
Message-Id: <1354650998.21742.140661161849669.1371855A@webmail.messagingengine.com>
From: Jim <jim618@fastmail.co.uk>
To: bitcoin-development@lists.sourceforge.net
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
In-Reply-To: <mailman.70419.1354648162.2176.bitcoin-development@lists.sourceforge.net>
References: <mailman.70419.1354648162.2176.bitcoin-development@lists.sourceforge.net>
Date: Tue, 04 Dec 2012 19:56:38 +0000
Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
Precedence: list

I think Alan's list of 'what should an ideal first client look like' is
right here.

From the first time user's perspective if they can get up and running
relatively quickly but still have the safety of a deterministic wallet
then they should have a good first user experience. MultiBit is not
there yet, but BIP32 support is on the roadmap.

If we have a 'shopping list' of what we want in a first client then that
gives me (and others) a list of what to focus on implementing.

Also, as BIP32 support is added to clients and codebases then the actual
variant of software to use to access your wallet will become relatively
less important. Combined with a standardised seed -> passphrase
algorithm the user can just type in their long passphrase into any BIP32
compliant software and click/ buzz/ whirr : there is their wallet. We
should have a little logo for HD wallet compliance ! :-)

As Bitcoin's users become more varied there will be a spectrum of how
'involved' they want to be computationally so we should have offerings
to reflect this.


On Tue, Dec 4, 2012, at 07:09 PM,
bitcoin-development-request@lists.sourceforge.net wrote:
> Send Bitcoin-development mailing list submissions to
> 	bitcoin-development@lists.sourceforge.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> or, via email, send a message with subject or body 'help' to
> 	bitcoin-development-request@lists.sourceforge.net
> 
> You can reach the person managing the list at
> 	bitcoin-development-owner@lists.sourceforge.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bitcoin-development digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Roadmap to getting users onto SPV clients (Alan Reiner)
>    2. Re: Roadmap to getting users onto SPV clients (Gregory Maxwell)
>    3. Re: Roadmap to getting users onto SPV clients (Mark Friedenbach)
>    4. Re: Roadmap to getting users onto SPV clients (Will)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 4 Dec 2012 13:03:11 -0500
> From: Alan Reiner <etotheipi@gmail.com>
> Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV
> 	clients
> To: Mike Hearn <mike@plan99.net>
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Message-ID:
> 	<CALf2ePzFZLmQ2+0hmOO0m_=EFy5mOtJ22jy2CYMxmU5U5e3s1w@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> My personal opinion is that the ideal first client has three features:
> 
> (1) Starts up and is usable within a couple minutes (even 10 min the
> first
> time would be okay, to sync block headers)
> (2) Supports Windows, Linux and OSX
> (3) Uses deterministic wallets that can produce a permanent backup
> (preferably paper)
> 
> Encryption is a major upside, too, but people new enough to Bitcoin that
> they need such a simple client, can survive without encryption (thye're
> not
> going to be holding a ton of coins) -- as long as they are made aware
> that
> they do not currently have encryption, and the associated risks (and
> other
> options).
> 
> I think it's extremely important that users have a clear way to backup
> their coins to offline media or paper, in such a way that they don't ever
> need to worry about it again.  Not only does it give users protection
> against hard-drive loss, it means that they may find it again in the far
> future when they haven't used Bitcoin in 2 years, and it reminds them
> that
> they still have coins (and they don't have to type in 1000 private keys
> to
> get their coins)
> 
> For that reason, I think Multibit is an excellent choice.  I haven't
> spent
> much time with it, but I do understand it to  satisfy (1) and (2)
> clearly,
> and (3) may be happening in the near future (along with encryption).  But
> I
> do wonder if it has enough staffing behind it to be the center of
> attention
> (no offense to jim618, but if this becomes the "de-facto" client for new
> users, we should make sure there's a lot of people available to support
> it
> -- what if a major security bug is found?  how long would it take the
> current team to identify, fix and test that bug?)
> 
> -Alan
> 
> 
> On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn <mike@plan99.net> wrote:
> 
> > At the moment if you visit bitcoin.org then you're recommended to
> > download the full client. I think we all agree that at some point we
> > need to start presenting users with something more like this:
> >
> >
> > To get started, download wallet apps A or B.
> >
> > If you'd like to contribute your computing resources to the Bitcoin
> > network and have a fast computer with an unfiltered internet
> > connection, download:
> >
> >    - for desktop machines, Bitcoin-Qt
> >    - for servers, bitcoind
> >
> >
> >
> > Obviously not that exact wording.
> >
> > I personally feel it's a bit early for this, but it's true that users
> > are being turned away by the fact that they're pointed to Bitcoin-Qt
> > by default, so having some kind of roadmap or plan for changing that
> > would be good.
> >
> > I think MultiBit is maturing into a client that I'd feel comfortable
> > recommending to end users who take the fast-start path, though it
> > still has a few serious lacks (encrypted wallets aren't released yet,
> > bloom filters will help performance a lot, needs to catch up with some
> > newer features). But there doesn't have to be a one true client.
> >
> > 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. MultiBit has some unique features that
> > are quite useful like integrating charting and exchange rate feeds.
> >
> > What does everyone think on this?
> >
> >
> > ------------------------------------------------------------------------------
> > 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 4 Dec 2012 13:17:42 -0500
> From: Gregory Maxwell <gmaxwell@gmail.com>
> Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV
> 	clients
> To: Mike Hearn <mike@plan99.net>
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Message-ID:
> 	<CAAS2fgQYV7aR86QOwvqMLpFZ+MAwSOSZvV6XuZdXvqjeYziRng@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> 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.
> 
> ? 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.
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 4 Dec 2012 10:57:40 -0800
> From: Mark Friedenbach <mark@monetize.io>
> Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV
> 	clients
> To: Mike Hearn <mike@plan99.net>
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Message-ID:
> 	<CACh7GpHUE2CYAMfRdAVPv1WAk102z94KYCWPV87fzzQEaP_hfw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Alan's UTxO meta-chain proposal becomes vastly easier to do now that
> ultraprune is merged. That would allow the Satoshi client to know it's
> wallet balance and operate with a >=SPV level of security during the
> initial block download, and keep them on the path of becoming a full
> node.
> If users can see their balances, send and receive transactions, and
> otherwise go about their business (except for mining) during the initial
> block download, would that not address your concerns?
> 
> IMHO the only time bitcoin.org should recommend a SPV-only client is when
> it is dynamically when it is being accessed from a mobile device, but
> that's a separate issue.
> 
> Mark
> 
> 
> On Tue, Dec 4, 2012 at 9:46 AM, Mike Hearn <mike@plan99.net> wrote:
> 
> > At the moment if you visit bitcoin.org then you're recommended to
> > download the full client. I think we all agree that at some point we
> > need to start presenting users with something more like this:
> >
> >
> > To get started, download wallet apps A or B.
> >
> > If you'd like to contribute your computing resources to the Bitcoin
> > network and have a fast computer with an unfiltered internet
> > connection, download:
> >
> >    - for desktop machines, Bitcoin-Qt
> >    - for servers, bitcoind
> >
> >
> >
> > Obviously not that exact wording.
> >
> > I personally feel it's a bit early for this, but it's true that users
> > are being turned away by the fact that they're pointed to Bitcoin-Qt
> > by default, so having some kind of roadmap or plan for changing that
> > would be good.
> >
> > I think MultiBit is maturing into a client that I'd feel comfortable
> > recommending to end users who take the fast-start path, though it
> > still has a few serious lacks (encrypted wallets aren't released yet,
> > bloom filters will help performance a lot, needs to catch up with some
> > newer features). But there doesn't have to be a one true client.
> >
> > 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. MultiBit has some unique features that
> > are quite useful like integrating charting and exchange rate feeds.
> >
> > What does everyone think on this?
> >
> >
> > ------------------------------------------------------------------------------
> > 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 4 Dec 2012 18:08:01 +0000
> From: Will <will@phase.net>
> Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV
> 	clients
> To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Message-ID:
> 	<CAHQs=o72Q3_DXmg80KtJzJgRMVcG+S3HJnseR_yxmWOFVEqnLg@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> ...or should we be directing people to a (vetted) list of cloud services
> -
> I think this has a significantly lower entry cost than any client. I know
> the mybitcoin debacle has clouded (pun intended) people's views of these
> providers, but blockchain.info (for example) really does seem quite well
> engineered, and satisfies many of the features in particular a very low
> cost of entry, cross platform support and what appears to be very good
> security (e.g. two factor)
> 
> Will
> 
> On 4 December 2012 17:46, Mike Hearn <mike@plan99.net> wrote:
> 
> > At the moment if you visit bitcoin.org then you're recommended to
> > download the full client. I think we all agree that at some point we
> > need to start presenting users with something more like this:
> >
> >
> > To get started, download wallet apps A or B.
> >
> > If you'd like to contribute your computing resources to the Bitcoin
> > network and have a fast computer with an unfiltered internet
> > connection, download:
> >
> >    - for desktop machines, Bitcoin-Qt
> >    - for servers, bitcoind
> >
> >
> >
> > Obviously not that exact wording.
> >
> > I personally feel it's a bit early for this, but it's true that users
> > are being turned away by the fact that they're pointed to Bitcoin-Qt
> > by default, so having some kind of roadmap or plan for changing that
> > would be good.
> >
> > I think MultiBit is maturing into a client that I'd feel comfortable
> > recommending to end users who take the fast-start path, though it
> > still has a few serious lacks (encrypted wallets aren't released yet,
> > bloom filters will help performance a lot, needs to catch up with some
> > newer features). But there doesn't have to be a one true client.
> >
> > 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. MultiBit has some unique features that
> > are quite useful like integrating charting and exchange rate feeds.
> >
> > What does everyone think on this?
> >
> >
> > ------------------------------------------------------------------------------
> > 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> 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
> 
> 
> End of Bitcoin-development Digest, Vol 19, Issue 7
> **************************************************


-- 
http://multibit.org    Money, reinvented