[Bitcoin-development] Roadmap to getting users onto SPV clients

Wed Dec 5 05:38:00 UTC 2012

Gavin's grandma needs to be able to use bitcoin.  Here is a real world
sampling of the types of people wanting to use bitcoin but are having some
difficulty which I have collected from Facebook.  Should we listen to the
end user? :-P

*"what is the intention of Bitcoin? Is it supposed to be - eventually - for
dummies like myself or is it just for those individuals who are code and
algorithm writers? I downloaded a wallet but how do I know if I need more
software or a massive computer system to solve "the problem" for the next
block? With all the talk of mathematical problem solving on a world wide
network of computers I can't see a small laptop figuring out anything thus
not gaining any bitcoins. Why should I be interested in this if it appears
it's just for computer scientists?"*

*"hi, instaled bitcoin qt, but after it dowladed all the stuff, now i get
DEP protecction from windows, and it tells me bitcoinQT need to run with
DEP on, dont let me make an exception for it, nor work it i turn DEP only
for sys, so hwat i should do?"*

*"hi, i'm new to bitcoin, i got a bunch of free bitcoins from a bunch of
the free sites. how come when i tried to send my bitcoins to myself, it
says the fee exceeds the balance? I thought there was no fees?"*

*"Is there a way to speed up the process of synchronisation with the
network? It has been taken ages on my MAC.*
*Any help would be nice"*
*
*
*and more...*

Sorry if this doesn't belong to the bitcoin-development email list.  I just
see this as end-user/customer data gathering to refine the requirements,
since this is software engineering...isn't it?

Jim

On Tue, Dec 4, 2012 at 6:54 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> > Our divergence is on two points (personal opinions):
> >
> > (1) I don't think there is any real risk to the centralization of the
> > network by promoting a SPV (purely-consuming) node to brand-new users.
> > In my opinion (but I'm not as familiar with the networking as you), as
> > long as all full nodes are full-validation, the bottleneck will be
> > computation and bandwidth, long before a constant 10k nodes would be
> > insufficient to support propagating data through the network.
>
> Not so— a moderately fast multicore desktop machine can keep up with
> the maximum possible validation rate of the Bitcoin network and the
> bandwidth has a long term maximum rate of about 14kbit/sec— though
> you'll want at least ten times that for convergence stability and the
> ability feed multiple peers.
>
> Here are the worst blocks testnet3 (which has some intentionally
> constructed maximum sized blocks),E31230 :
> (with the new parallel validation code)
> - Verify 2166 txins: 250.29ms (0.116ms/txin)
> - Verify 3386 txins: 1454.25ms (0.429ms/txin)
> - Verify 5801 txins: 575.46ms (0.099ms/txin)
> - Verify 6314 txins: 625.05ms (0.099ms/txin)
> Even the slowest one _validates_ at 400x realtime. (these measurements
> are probably a bit noisy— but the point is that its fast).
> (the connecting is fast too, but thats obvious with such a small database)
>
> Although I haven't tested leveldb+ultraprune with a really enormous
> txout set or generally with sustained maximum load— so there may be
> other gaffs in the software that get exposed with sustained load, but
> they'd all be correctable. Sounds like some interesting stuff to test
> with on testnet fork that has the POW test disabled.
>
> While syncing up a behind node can take a while— keep in mind that
> you're expecting to sync up weeks of network work in hours. Even
> 'slow' is quite fast.
>
> > In fact,
> > I was under the impression that "connectedness" was the real metric of
> > concern (and resilience of that connectedness to large percentage of
> > users disappearing suddenly).  If that's true, above a certain number of
> > nodes, the connectedness isn't really going to get any better (I know
> > it's not really that simple, but I feel like it is up to 10x the current
> > network size).
>
> Thats not generally concern for me. There are a number of DOS attack
> risks... But attacker linear DOS attacks aren't generally avoidable
> and they don't persist.
>
> Of the class of connectedness concerns I have is that a sybil attacker
> could spin up enormous numbers of nodes and then use them to partition
> large miners.  So, e.g. find BitTaco's node(s) and the nodes for
> miners covering 25% hashpower and get them into a separate partition
> from the rest of the network. Then they give double spends to that
> partition and use them to purchase an unlimited supply of digitally
> delivered tacos— allowing their captured miners to build an ill fated
> fork— and drop the partition once the goods are delivered.
>
> But there is no amount of full nodes that removes this concern,
> especially if you allow for attackers which have compromised ISPs.
> It can be adequately addressed by a healthy darknet of private
> authenticated peerings between miners and other likely targets. I've
> also thrown out some ideas on using merged mined node IDs to make some
> kinds of sybil attacks harder ... but it'll be interesting to see how
> the deployment of ASICs influences the concentration of hashpower— it
> seems like there has already been a substantial move away from the
> largest pools. Less hashpower consolidation makes attacks like this
> less worrisome.
>
> > (2) I think the current experience *is* really poor.
>
> Yes, I said so specifically.  But the fact that people are flapping
> their lips here instead of testing the bitcoin-qt git master which is
> an 1-2 order of magnitude improvement suggests that perhaps I'm wrong
> about that.  Certainly the dearth of people testing and making bug
> reports suggests people don't actually care that much.
>
> > You seem to
> > suggest that the question for these new users is whether they will use
> > full-node-or-lite-node, but I believe it will be a decision between
> > lite-node-or-nothing-at-all (losing interest altogether).
>
> No. The "question" that I'm concerned with is do we promote lite nodes
> as equally good option— even for high end systems— remove the
> incentive for people to create, improve, and adopt more useful full
> node software and forever degrade the security of the system.
>
> > Waiting a day
> > for the full node to synchronize, and then run into issues like
> > blkindex.dat corruption when their system crashes for some unrelated
> > reason and they have to resync for another day... they'll be gone in a
> > heartbeat.
>
> The current software patches plus parallelism can sync on a fast
> system with luck network access (or a local copy of the data) in under
> an hour.
>
> This is no replacement for start as SPV, but nor are handicapped
> client programs a replacement for making fully capable ones acceptably
> performing.
>
> > Users need to experience, as quickly and easily as possible, that they
> > can move money across the world, without signing up for anything or
> > paying any fees.
>
> Making the all the software painless for users is a great goal— and
> one I share.  I still maintain that it has nothing to do with
> promoting less capable and secure software to users.
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121204/52b496b5/attachment.html>