diff options
author | Jim <jim618@fastmail.co.uk> | 2012-12-04 19:56:38 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2012-12-04 19:56:46 +0000 |
commit | d134525bad9585fc5eb300ef34acf6cfcaa218e8 (patch) | |
tree | e8ecc7939639fcca025e8b8524bf3720e6f94000 | |
parent | a8769d0735c3b5174b9ef9e7e268bd7eb18e1b78 (diff) | |
download | pi-bitcoindev-d134525bad9585fc5eb300ef34acf6cfcaa218e8.tar.gz pi-bitcoindev-d134525bad9585fc5eb300ef34acf6cfcaa218e8.zip |
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
-rw-r--r-- | 11/8bc780427cbffa1842ce524448510212d7daca | 477 |
1 files changed, 477 insertions, 0 deletions
diff --git a/11/8bc780427cbffa1842ce524448510212d7daca b/11/8bc780427cbffa1842ce524448510212d7daca new file mode 100644 index 000000000..d9cfb32c0 --- /dev/null +++ b/11/8bc780427cbffa1842ce524448510212d7daca @@ -0,0 +1,477 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <jim618@fastmail.co.uk>) id 1Tfybm-0007Po-9d + for bitcoin-development@lists.sourceforge.net; + Tue, 04 Dec 2012 19:56:46 +0000 +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; +Received: from out4-smtp.messagingengine.com ([66.111.4.28]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) + (Exim 4.76) id 1Tfybk-0005iQ-29 + for bitcoin-development@lists.sourceforge.net; + Tue, 04 Dec 2012 19:56:46 +0000 +Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) + by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8291D2074C + for <bitcoin-development@lists.sourceforge.net>; + Tue, 4 Dec 2012 14:56:38 -0500 (EST) +Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) + by compute3.internal (MEProxy); Tue, 04 Dec 2012 14:56:38 -0500 +Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) + id 48142212CA; Tue, 4 Dec 2012 14:56:38 -0500 (EST) +Message-Id: <1354650998.21742.140661161849669.1371855A@webmail.messagingengine.com> +X-Sasl-Enc: NqdL9uQsrNnCuR1AZnFNUJYPP7J6YKY1JqQoCsrtTw4I 1354650998 +From: Jim <jim618@fastmail.co.uk> +To: bitcoin-development@lists.sourceforge.net +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Content-Type: text/plain +X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8b16d3 +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 +X-Spam-Score: -1.4 (-) +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 + (jim618[at]fastmail.co.uk) + -0.0 SPF_PASS SPF: sender matches SPF record + 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in + digit (jim618[at]fastmail.co.uk) + -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: 1Tfybk-0005iQ-29 +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Tue, 04 Dec 2012 19:56:46 -0000 + +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 + + |