summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJim <jim618@fastmail.co.uk>2012-12-04 19:56:38 +0000
committerbitcoindev <bitcoindev@gnusha.org>2012-12-04 19:56:46 +0000
commitd134525bad9585fc5eb300ef34acf6cfcaa218e8 (patch)
treee8ecc7939639fcca025e8b8524bf3720e6f94000
parenta8769d0735c3b5174b9ef9e7e268bd7eb18e1b78 (diff)
downloadpi-bitcoindev-d134525bad9585fc5eb300ef34acf6cfcaa218e8.tar.gz
pi-bitcoindev-d134525bad9585fc5eb300ef34acf6cfcaa218e8.zip
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
-rw-r--r--11/8bc780427cbffa1842ce524448510212d7daca477
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
+
+