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

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

[Jim]

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

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

[slush]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

Jim, perfect idea with some logo indicating wallet compatibility! This
should cover BIP32 + some mnemonic algorithm for easy transferring of
wallets across various clients.

Btw I asked ThomasV for making BIP from his mnemonic algorithm and he
agreed, so I believe some proposal will be here pretty soon.

slush

On Tue, Dec 4, 2012 at 7:56 PM, Jim <jim618@fastmail.co.uk> wrote:
>
> 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 ! :-)
>
>

[-- Attachment #2: Type: text/html, Size: 1239 bytes --]

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

[Mike Hearn]

>> I was under the impression that "connectedness" was the real metric of
>> concern

I think the real thing we need full nodes for is "sockets" where by
socket I mean "resources needed to serve another node".

Last year we actually ran out of sockets and it took forever for new
nodes to connect because so many existing nodes were full. We don't
want to be in that situation again. So we need full nodes, nobody
disputes that.

The question is, if you have a node on your average desktop machine
that gets switched off at night, has a stupid virus scanner that
insists on checking every database write, has users who go from a bit
of light word processing to watching HD video and expect no stutters
or slowdowns - how valuable is such a node, really? Also has to be
weighed against the risk of eventual user frustration when they
discover Bitcoin is slowing their computer down and go around telling
their friends how much it sucks.

Ultraprune+LevelDB+other optimizations are great. They aren't game
changers for two reasons:

1) Eventually network traffic should increase to use up the additional
performance unlocked by optimizations

2) Users demand instant on not just at first start, but any time they
open their wallet. I don't think it ever makes sense for a regular end
user to have their wallet integrated with a full node because it means
if you get an email saying "oh hey I sent you the money" and you start
your wallet so you can see it/spend it, you still have to wait a while
until it catches up from whenever it was last quit. I've done this a
bunch of times and it really sucks to wait.

The only time it makes sense to have a wallet integrated with a full
node is if that node never shuts down, ie, it's a merchant node.

If a casual user has to be using an SPV wallet all the time no matter
what, then it's not a big leap to simply have both an SPV client and a
full node running in parallel for users who want to support the
network. And how do we recruit such users? Well I've got nothing
against light wallets noticing that the system seems to have high
uptime, external connectivity etc and putting a notice on the screen
asking users to take part. For Windows users you could have a
one-click install that sets up a background service (I think .NET
OneClick makes this possible), so getting a full node is totally easy
and transparent.

Going back to the Tor analogy, whilst I agree with Gregorys arguments
that they aren't quite the same, the Tor guys have wanted to
automatically opt users in to being relays for a while. But the
technical complexity of doing it well is really high. It's still on
their wishlist even though Tor is quite old. A good first base to
reach is simply having accurate recommendations. If users start
complaining that they were asked to run a full node but when they did,
performance suffered unacceptably, then we know we need better
heuristics before automatically opting users in.

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

[Robert Backhaus]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

On 5 December 2012 19:43, Gary Rowe <g.rowe@froot.co.uk> wrote:

> I would like to chime on on the user experience of the SPV client (in
> particular MultiBit).
>
> Without exception, everyone that I have introduced Bitcoin (which is a lot
> of people) have expected an "instant-on" experience. It has to clobber
> PayPal and credit cards or people won't give it a second look, let alone a
> second chance. SPV clients deliver on that expectation.
>
> Once the user has the great initial "wow!" moment then their interest in
> Bitcoin is reinforced and they tend to explore further, particularly into
> the economic theory behind it. Many decide to install the full node out of
> a sense of community contribution to the security of the network.
>
> Having a hybrid mode of SPV first then full node second should be
> something that a user has control over - it is their computing resources we
> are using after all and Bitcoin should not be perceived as a drain.


Hybrid SPV sounds like a good idea to me. Allows it to work out-of-the-box,
then slowly gets up-to-speed with the full network - working low priority,
or even not at all, if it detects a slow system or network link.
Another idea is always distributing the client with a checkpoint that is
only days old, then starting by pulling in more recent blocks, so it can
transact. Following that, it will pull in progressively older blocks as
time permits.

[-- Attachment #2: Type: text/html, Size: 1730 bytes --]

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

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 12438 bytes --]

I would like to chime on on the user experience of the SPV client (in
particular MultiBit).

Without exception, everyone that I have introduced Bitcoin (which is a lot
of people) have expected an "instant-on" experience. It has to clobber
PayPal and credit cards or people won't give it a second look, let alone a
second chance. SPV clients deliver on that expectation.

Once the user has the great initial "wow!" moment then their interest in
Bitcoin is reinforced and they tend to explore further, particularly into
the economic theory behind it. Many decide to install the full node out of
a sense of community contribution to the security of the network.

Having a hybrid mode of SPV first then full node second should be something
that a user has control over - it is their computing resources we are using
after all and Bitcoin should not be perceived as a drain.


On 5 December 2012 07:50, Wladimir <laanwj@gmail.com> wrote:

> Jim,
>
> Most of those issues don't have to do with the SPV versus non-SPV problem.
>
> First person doesn't understand what Bitcoin is supposed to do (he's
> confusing mining and running a node). An information problem that could be
> solved by explaining what is going on.
>
> Another one seems to have a problem with DEP. That's probably an issue
> with his OS configuration.
>
> The third one is confused about the fees. Again, an information problem.
>
> Only the fourth one is concerned with synchronization. The other ones
> could happen with any client, as they're either based on misconceptions
> about bitcoin as a whole or computer problems.
>
> This doesn't in any way make switching to another, reduced security model
> client preferable. Let's first try to improve the Bitcoin experience with
> full security model, and if that somehow turns out to be impossible it's
> always possible to recommend some other client based on the 'user type'.
>
> I don't agree that this point is now. Anyway, security and stability of
> the network is of utmost importance to do anything in the future, better to
> grow organically than explode.
>
> Many initiatives are underway to improve the Satoshi client (for
> example to have Bitcoin-Qt behave as SPV client during initial block
> download, and as full node after that), but as usual in open source
> development, many of us are doing this basically for fun in our free time
> it does not always go as fast as users would like.
>
> I wish there was a straightforward solution for that, yeah pooling
> together our development on one or two clients instead of a zillion
> different ones could help, but everyone has more fun working on their own
> client that's just how things go :)
>
> Wladimir
>
> On Wed, Dec 5, 2012 at 6:38 AM, Jim Nguyen <jimmy.winn@gmail.com> wrote:
>
>> 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@gmail.com>wrote:
>>
>>> On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner <etotheipi@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@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 15140 bytes --]

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

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 10618 bytes --]

Jim,

Most of those issues don't have to do with the SPV versus non-SPV problem.

First person doesn't understand what Bitcoin is supposed to do (he's
confusing mining and running a node). An information problem that could be
solved by explaining what is going on.

Another one seems to have a problem with DEP. That's probably an issue with
his OS configuration.

The third one is confused about the fees. Again, an information problem.

Only the fourth one is concerned with synchronization. The other ones could
happen with any client, as they're either based on misconceptions about
bitcoin as a whole or computer problems.

This doesn't in any way make switching to another, reduced security model
client preferable. Let's first try to improve the Bitcoin experience with
full security model, and if that somehow turns out to be impossible it's
always possible to recommend some other client based on the 'user type'.

I don't agree that this point is now. Anyway, security and stability of the
network is of utmost importance to do anything in the future, better to
grow organically than explode.

Many initiatives are underway to improve the Satoshi client (for example to
have Bitcoin-Qt behave as SPV client during initial block download, and as
full node after that), but as usual in open source development, many of us
are doing this basically for fun in our free time it does not always go as
fast as users would like.

I wish there was a straightforward solution for that, yeah pooling together
our development on one or two clients instead of a zillion different ones
could help, but everyone has more fun working on their own client that's
just how things go :)

Wladimir

On Wed, Dec 5, 2012 at 6:38 AM, Jim Nguyen <jimmy.winn@gmail.com> wrote:

> 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@gmail.com>wrote:
>
>> On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner <etotheipi@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@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 12874 bytes --]

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

[Jim Nguyen]

[-- Attachment #1: Type: text/plain, Size: 7995 bytes --]

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@gmail.com> wrote:

> On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner <etotheipi@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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 9412 bytes --]

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

[Gregory Maxwell]

On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner <etotheipi@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.

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

[Alan Reiner]

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.  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).

(2) I think the current experience *is* really poor.  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).  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.

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.  After they understand the value of the system and want
to use it, they are much more likely to become educated and willing to
support the network with full node. 

-Alan




On 12/04/2012 07:27 PM, Gregory Maxwell wrote:
> On Tue, Dec 4, 2012 at 5:44 PM, Alan Reiner <etotheipi@gmail.com> wrote:
>> Greg's point looks like it's veering towards "we don't want to grow
>> the network unless we're going to get more full nodes out of it."
> No…
>
> There is no fundamental completion between taking what actions we can
> to maximize the decentralization of the network and making the
> software maximally friendly and painless to get started with and use.
> It's possible— not even deep rocket science— to create software that
> accommodates both.
>
> And because of this, I don't think it's acceptable to promote
> solutions which may endanger the decentralization that makes the
> system worthwhile in the first place.  If the current experience is so
> poor that you'd even consider talking about promoting directions which
> reduce its robustness then thats evidence that it would be worth
> finding more resources to make the experience better without doing
> anything the that reduces the model, even if you've got an argument
> that maybe we can get away with it.  If there isn't interest in
> putting in more resources to make these improvements then maybe the
> issue isn't as bad as we think it is?
>
>> I think it is very much in everyone's interest here to encourage new users to start "using" Bitcoin, even if they don't "support" it.
> Absolutely— and yet that has nothing to do with promoting software to
> users which only consumes without directly contributing and which
> doesn't even have the capability to do so even if the user wants to
> (or much less, is indifferent).

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

[Gregory Maxwell]

On Tue, Dec 4, 2012 at 5:44 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> Greg's point looks like it's veering towards "we don't want to grow
> the network unless we're going to get more full nodes out of it."

No…

There is no fundamental completion between taking what actions we can
to maximize the decentralization of the network and making the
software maximally friendly and painless to get started with and use.
It's possible— not even deep rocket science— to create software that
accommodates both.

And because of this, I don't think it's acceptable to promote
solutions which may endanger the decentralization that makes the
system worthwhile in the first place.  If the current experience is so
poor that you'd even consider talking about promoting directions which
reduce its robustness then thats evidence that it would be worth
finding more resources to make the experience better without doing
anything the that reduces the model, even if you've got an argument
that maybe we can get away with it.  If there isn't interest in
putting in more resources to make these improvements then maybe the
issue isn't as bad as we think it is?

> I think it is very much in everyone's interest here to encourage new users to start "using" Bitcoin, even if they don't "support" it.

Absolutely— and yet that has nothing to do with promoting software to
users which only consumes without directly contributing and which
doesn't even have the capability to do so even if the user wants to
(or much less, is indifferent).

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

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 10268 bytes --]

This discussion sounds to be veering slightly off track.  I think we should
be focusing on how we will ease the transition for new users to get on the
network and use it.  Talking about the necessity and costs of running full
nodes in the future is important, but irrelevant here:  unless we don't
want users who aren't willing to run full nodes, we need to accommodate
users who want to simply "use" the network, not necessarily "support" it.  *I'm
making an assumption here that we want new users whether they use a full
node or not*.  Greg's point looks like it's veering towards "we don't want
to grow the network unless we're going to get more full nodes out of it."
  I'm of the opinion, like Mike Hearn, that the number of full nodes needed
for a healthy network is *not* O(N) in the number of users of the network.
 I expect it to be something more like O(sqrt(N))... or perhaps there's
even an upper limit above which the network gets no benefit, even if all 7
billion humans were using it.  (the bottleneck would be size of blocks and
CPU processing power at that point, not a shortage of full nodes).  Would
we rather have a system that is "full-node-or-nothing" and drive away users
that won't support the network, or accommodate those users with various
gradations of participation?

I believe my proposal for an address-based meta-chain (or something like
it) is *exactly* what is needed in the long run.  It could almost obsolete
this entire discussion.  However, as Greg pointed out there is a long,
treacherous path between the theory I presented, and a working&robust
implementation that can serve as the backbone for future SPV nodes.  I have
every intention to help pioneer that when Armory has other major features
completed (such as multi-sig), but it's not something that we can even
consider in the near- or medium-term as a solution to rely on.  I'd be
surprised if any such solution existed in the next 6-12 months.

I think it is very much in everyone's interest here to encourage new users
to start "using" Bitcoin, even if they don't "support" it.  As long as
there is a convenient channel for interested users to get more information
about the system, the benefits of spending the effort to run a full node,
and the features available in more-advanced clients that they might benefit
from, then I'm not personally concerned about a shortage of full nodes, and
we should carry forward with the idea of promoting SPV nodes for the
really-new users.

-Alan




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

> On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn <mike@plan99.net> wrote:
> >> 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.
> >
> > Hardly. I don't have any particular timeline in mind. But I disagree
> > we have "forever". New ideas have a certain time window to take off
> > and become credible.
>
> Marketing initiatives have limited windows.  This matters, perhaps,
> when you're some VC pumping cash into a startup with the hopes of
> being the next stockmarket pump and dump darling.  Outside of that
> people use whatever they use because it works for them.
>
> And by the numbers Linux desktops are more common than they've ever
> been— and certainly Linux kernel _systems_ half the people I know have
> one in their pocket and its hard to go more than a few hours without
> touching one.  To some extent the "Year of the Linux desktop" is a bit
> like the "Year of being able to turn lead into gold" ... we can turn
> lead into gold now, but the particle accelerators, atomic power, and
> atomic weapons enabled by the same technology are far more interesting
> due to the particle realities of this. So we didn't get the ubiquitous
> Linux desktop: We got the ubiquitious Linux server, the ubiquitous
> Linux-kernel smart phone, the ubiquitous Linux television, media
> player, HVAC controller, etc. instead.
>
> Desktops— well, that didn't meet people's hopes though I think not for
> the lack of marketing on the part of Linux, but because Apple stepped
> up and produced middle ground products that attracted a larger
> audience. Especially as MSFT dropped the ball. They did some things
> better, had a running start, and had a non open source software
> business model which made reaping rewards easier.
>
> But I don't see how any of this has anything to do with Bitcoin...
> Except for the point that if Bitcoin doesn't become the money system
> everyone uses and instead becomes the money system infrastructure all
> the systems people use depend on— just as Linux has with the desktop,
> where it might not be on the desktop but its in router firmware, cloud
> servers, and just about everything else— I wouldn't consider that much
> of a loss.
>
> > time window, eventually people just give up and move on. Does anyone
> > take desktop Linux seriously anymore? No. "The year of desktop Linux"
> > is a joke. People took it seriously in 2001 but despite great progress
> > since, the excitement and attention has gone. There were steady
> > improvements over the last 10 years but nobody is creating desktop
> > Linux startups anymore
>
> Bitcoin already missed its first— and perhaps only— fad window in any
> case. Today people say "Bitcoin? Thats still around? I thought it got
> hacked". ... thanks to compromised centralized services.
>
> > It's unclear we need to have every man and his dog run a full node.
>
> Every man and his dog? Perhaps not.  But as many as can— probably so.
>
> If we depend on the organic need for full nodes to overcome cost and
> effort to run one there will always be major incentives to let someone
> else do that, and the system would have its equilibrium right on the
> brink of insecurity. Perhaps worse, since insecurity is most obvious
> retrospectively. Security doesn't make for a good market force.
>
> > Tor is a successful P2P network where the number of users vastly
> > outstrips the number of nodes, and exit nodes in particular are a
> > scarce resource run by people who know what they're doing and commit
> > to it.
>
> Tor is a distributed but controlled, by a small number of directory
> authority operators, system.
>
> It is a good system. But it has a trust model which is categorically
> weaker than the one in Bitcoin.  If you want something where a
> majority of a dozen signing keys— hopefully in the hands of trusted
> parties— can decide the state of the system you can produce someting
> far superior to Bitcoin— something that gives near instant
> non-reversable transactions, something that gives good client security
> without the complexity of a SPV node, etc.
>
> But that isn't Bitcoin.
>
> > Even with no incentives, they were able to obtain
> > the resources they need.
>
> And yet every tor user— if the have the bandwidth available can be a
> full internal relay and the software nags them to do it (and also nags
> them to act as invisible bridges for blocking avoidance), and every
> user is technically able to run an exit (though they don't bludgeon
> users to do that, because of the legal/political/technical issues
> involved).  To do any of this doesn't require a user to switch to
> different software, and the tor project has previously opposed client
> only software.
>
> > So why should Bitcoin be different?
>
> It's less different than you make it out to be— but it _is_ different.
>   Bitcoin is a distributed currency. The value of bitcoin comes from
> the soundness of its properties and from the persistence of its
> security. If the integrity of the distributed ledger is disrupted the
> damage produced, both in funds stolen and in undermining the
> confidence of the system, can be irreversible. Because Bitcoin's value
> comes from confidence in Bitcoin and not from the specific
> functionality of Bitcoins (they're random numbers that sit on your
> disk) even if the ledger isn't actually compromised but people
> reasonably believe it could be compromised that undermines the value.
>  Tor, on the other hand, is a functioning system whos value depends on
> its current usefulness, and not the past or future security.
>
> Compare in your mind— Say everyone just found out that at block
> 420,000 Bitcoin would stop enforcing signature correctness or block
> subsidy values (and this wasn't going to be fixed), and you also found
> out that one year from now Tor would hand over their sites, source
> code repositories, and directory authority keys to Iran (and you have
> no suspicion that they already had done so).   How fast would you stop
> using Tor vs how fast would to sell whatever coins you could?
>
> > We can easily send a clear and consistent "this is important, please
> > help" message without complicated auto-upgrade/downgrade schemes that
> > risk annoying users.
>
> I don't think we really can send such a message.  Thanks just the same
> as asking for donations, not completely unsuccessful but not easy to
> make successful either.  You're arguing for people running distinct
> software which has no capability to be a full node, and changing what
> they're doing in order to support the network. This maximizes the
> cost, because in addition to the real cost the user must take a
> switching cost too, and deemphasizes investing in keeping the full
> node software as usable because 'oh just run a lite node if the full
> is too slow'.
>
>
> ------------------------------------------------------------------------------
> 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
>

[-- Attachment #2: Type: text/html, Size: 11840 bytes --]

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

[Gregory Maxwell]

On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn <mike@plan99.net> wrote:
>> 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.
>
> Hardly. I don't have any particular timeline in mind. But I disagree
> we have "forever". New ideas have a certain time window to take off
> and become credible.

Marketing initiatives have limited windows.  This matters, perhaps,
when you're some VC pumping cash into a startup with the hopes of
being the next stockmarket pump and dump darling.  Outside of that
people use whatever they use because it works for them.

And by the numbers Linux desktops are more common than they've ever
been— and certainly Linux kernel _systems_ half the people I know have
one in their pocket and its hard to go more than a few hours without
touching one.  To some extent the "Year of the Linux desktop" is a bit
like the "Year of being able to turn lead into gold" ... we can turn
lead into gold now, but the particle accelerators, atomic power, and
atomic weapons enabled by the same technology are far more interesting
due to the particle realities of this. So we didn't get the ubiquitous
Linux desktop: We got the ubiquitious Linux server, the ubiquitous
Linux-kernel smart phone, the ubiquitous Linux television, media
player, HVAC controller, etc. instead.

Desktops— well, that didn't meet people's hopes though I think not for
the lack of marketing on the part of Linux, but because Apple stepped
up and produced middle ground products that attracted a larger
audience. Especially as MSFT dropped the ball. They did some things
better, had a running start, and had a non open source software
business model which made reaping rewards easier.

But I don't see how any of this has anything to do with Bitcoin...
Except for the point that if Bitcoin doesn't become the money system
everyone uses and instead becomes the money system infrastructure all
the systems people use depend on— just as Linux has with the desktop,
where it might not be on the desktop but its in router firmware, cloud
servers, and just about everything else— I wouldn't consider that much
of a loss.

> time window, eventually people just give up and move on. Does anyone
> take desktop Linux seriously anymore? No. "The year of desktop Linux"
> is a joke. People took it seriously in 2001 but despite great progress
> since, the excitement and attention has gone. There were steady
> improvements over the last 10 years but nobody is creating desktop
> Linux startups anymore

Bitcoin already missed its first— and perhaps only— fad window in any
case. Today people say "Bitcoin? Thats still around? I thought it got
hacked". ... thanks to compromised centralized services.

> It's unclear we need to have every man and his dog run a full node.

Every man and his dog? Perhaps not.  But as many as can— probably so.

If we depend on the organic need for full nodes to overcome cost and
effort to run one there will always be major incentives to let someone
else do that, and the system would have its equilibrium right on the
brink of insecurity. Perhaps worse, since insecurity is most obvious
retrospectively. Security doesn't make for a good market force.

> Tor is a successful P2P network where the number of users vastly
> outstrips the number of nodes, and exit nodes in particular are a
> scarce resource run by people who know what they're doing and commit
> to it.

Tor is a distributed but controlled, by a small number of directory
authority operators, system.

It is a good system. But it has a trust model which is categorically
weaker than the one in Bitcoin.  If you want something where a
majority of a dozen signing keys— hopefully in the hands of trusted
parties— can decide the state of the system you can produce someting
far superior to Bitcoin— something that gives near instant
non-reversable transactions, something that gives good client security
without the complexity of a SPV node, etc.

But that isn't Bitcoin.

> Even with no incentives, they were able to obtain
> the resources they need.

And yet every tor user— if the have the bandwidth available can be a
full internal relay and the software nags them to do it (and also nags
them to act as invisible bridges for blocking avoidance), and every
user is technically able to run an exit (though they don't bludgeon
users to do that, because of the legal/political/technical issues
involved).  To do any of this doesn't require a user to switch to
different software, and the tor project has previously opposed client
only software.

> So why should Bitcoin be different?

It's less different than you make it out to be— but it _is_ different.
  Bitcoin is a distributed currency. The value of bitcoin comes from
the soundness of its properties and from the persistence of its
security. If the integrity of the distributed ledger is disrupted the
damage produced, both in funds stolen and in undermining the
confidence of the system, can be irreversible. Because Bitcoin's value
comes from confidence in Bitcoin and not from the specific
functionality of Bitcoins (they're random numbers that sit on your
disk) even if the ledger isn't actually compromised but people
reasonably believe it could be compromised that undermines the value.
 Tor, on the other hand, is a functioning system whos value depends on
its current usefulness, and not the past or future security.

Compare in your mind— Say everyone just found out that at block
420,000 Bitcoin would stop enforcing signature correctness or block
subsidy values (and this wasn't going to be fixed), and you also found
out that one year from now Tor would hand over their sites, source
code repositories, and directory authority keys to Iran (and you have
no suspicion that they already had done so).   How fast would you stop
using Tor vs how fast would to sell whatever coins you could?

> We can easily send a clear and consistent "this is important, please
> help" message without complicated auto-upgrade/downgrade schemes that
> risk annoying users.

I don't think we really can send such a message.  Thanks just the same
as asking for donations, not completely unsuccessful but not easy to
make successful either.  You're arguing for people running distinct
software which has no capability to be a full node, and changing what
they're doing in order to support the network. This maximizes the
cost, because in addition to the real cost the user must take a
switching cost too, and deemphasizes investing in keeping the full
node software as usable because 'oh just run a lite node if the full
is too slow'.

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

[Mike Hearn]

> 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.

Hardly. I don't have any particular timeline in mind. But I disagree
we have "forever". New ideas have a certain time window to take off
and become credible. If they never overcome their problems in that
time window, eventually people just give up and move on. Does anyone
take desktop Linux seriously anymore? No. "The year of desktop Linux"
is a joke. People took it seriously in 2001 but despite great progress
since, the excitement and attention has gone. There were steady
improvements over the last 10 years but nobody is creating desktop
Linux startups anymore - Bitcoin shouldn't go the same way.

It's unclear we need to have every man and his dog run a full node.
Tor is a successful P2P network where the number of users vastly
outstrips the number of nodes, and exit nodes in particular are a
scarce resource run by people who know what they're doing and commit
to it.

The Tor guys could have said "every node should be an exit if
possible", but that would have been a short term optimization at the
cost of long term stability, and anyway doesn't seem to have been
necessary so far. Even with no incentives, they were able to obtain
the resources they need.

So why should Bitcoin be different? If there are a million users
supported by 50,000 full nodes, that wouldn't sound unhealthy to me.
We can easily send a clear and consistent "this is important, please
help" message without complicated auto-upgrade/downgrade schemes that
risk annoying users.

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

[Gregory Maxwell]

On Tue, Dec 4, 2012 at 1:57 PM, Mark Friedenbach <mark@monetize.io> wrote:
> Alan's
  :(

> UTxO meta-chain proposal becomes vastly easier to do now that
> ultraprune is merged.

No, not really. Somewhat easier due to some structural changes, but it
still needs to invent and get consensus on a normative data structure
and people need to write implementations of the required operations on
it (implementations probably required to prove performance for
consensus).  We still have to sort through the tradeoff of making a
_single_ data structure the normative merkle tree representation for
the UTxO set to the preclusion of other implementations— including
ones which are  asymptotically faster, such as a straight hash table.

There are also issues that need to be sorted out like key structure—
the most useful index for validation is txid:vout keyed, but Alan
wanted 'address' prefixed, which is not friendly for validation but
enables robust query by address— a query that the referce normal
bitcoin software doesn't even optionally support right now.  Any
disagreements on this point must be hammed out because the structure
would be normative.

> 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?

The above said, that is all good stuff too. And I do thing starting
fast with reduced security (be it to SPV+ or SPV) is a good idea.

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

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 2755 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3557 bytes --]

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

[Gregory Maxwell]

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.

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

[Will]

[-- Attachment #1: Type: text/plain, Size: 2564 bytes --]

...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
>

[-- Attachment #2: Type: text/html, Size: 3350 bytes --]

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

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 3757 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4742 bytes --]

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

[Mike Hearn]

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?