Cool, thanks for the detailed info
If you happen to have trend graphs of the charged wallets or a grand total of Ƀs Spinner is being trusted with, I would be very curious to see these


As you might guess from what I said above, I see no problem in stating what Jan stated above at all. Telling that x wallets hold 1 Satoshi or more is only stating that these people actually have and maybe use (certainly used) an account as opposed to had an account that they maybe used or not.

Spinner has a technical necessity for "eavesdropping" and adding a report-balance functionality to Bitcoin Wallet would indeed be more than rude so I hope that what you actually meant to say is that you do not have these numbers.

Hmm … now that I think about it:
Spinner needs a simple API. getBalance(address), maybe getHistory(address) and send(signedTransaction).
Without looking in the code I assume all this is publicly available even without Spinner, so I could have a website that uses your Spinner-server making you believe to have 10,000 wallets more and the numbers you named are actually addresses you ever received via the public getBalance API.

Anyway you should have a pretty clear picture of how many wallets are daily active, weekly active and monthly active although a sample of some 800 users is most likely not sufficient to get a consistent picture.

Well, of course I respectfully disagree.

SPV clients like Bitcoin Wallet can be instant-on. They are not today because the programming involved is tricky and not completed yet. But we'll get there eventually. I already find Bitcoin Wallet to catch up plenty fast enough if I enable the "sync on power" option, I think in future Andreas will make this option on by default so all users benefit. It means typically the client is only a few hours behind. And of course you can spend without being fully caught up to the chain head.

The primary remaining issues are reliability (if you connect to an overloaded peer sync can be very slow), storage costs (this can be solved quite easily), and bandwidth consumption, the fix for which is largely implemented by Matt and just needs review+merge+people to upgrade.

Running SPV on a phone is by far the hardest solution to make work well. It is also theoretically the best in terms of security, privacy and how closely it matches Satoshis vision of a truly P2P system. I think once the remaining performance problems are solved there won't be much incentive to use other types of wallet.

Any solution which involves keys being stored on the server is a non-starter for me. There have been too many cases of wallets hosted by third parties getting hacked. Not to mention the legal issues.

There are two ways you can cut data usage. One is to enable "Sync on power" in the preferences window, you can do that right now. It means it'll catch up with the chain at night when you are charging the phone and have your home wifi available.

A better way is using Bloom filters. See this thread from 2011 where I introduce the idea:

https://bt.irlbtc.com/view/7972.0

It has since been implemented by Matt. With Bloom filtering you can select any arbitrary point on the bandwidth usage/privacy spectrum. If you don't mind remote nodes learning some subset of your addresses you can reduce bandwidth usage down to the minimum theoretically possible - just transactions that send money to/from your wallet plus the headers (a few megabytes of data per year).

In the likely event that you'd prefer remote nodes to be somewhat fuzzy about what you own and you have bandwidth to spare, you can use a filter that has false positives (it matches more than it needs to). It means downloading some data you then throw away but the privacy is better.

Clients can select the FP rate of their filters depending on things like wifi vs 3G vs LTE, battery usage, how much data quota you have left, etc.

I don't want us to derail this thread with pros/cons of various services, and I don't want to throw mud,  but I'll have to defend myself here.
I agree that a compromised Spinner server can lie about your balance. The damage is limited and once this happens everyone will know pretty quickly.
However, the difference is very simple: With the Spinner, whoever controls the server cannot run away with the coins.

Using the "our servers have never been hacked" argument is lame and you know it. We have seen many examples where so called secure systems have been hacked. All it takes is one disgruntled employee.

I am all for diversity, and I think we should focus on making the Bitcoin pie larger instead of fighting over the scraps. I would much rather read a thread where Paytunia describes why the service is secure (is there a firewall, is there cold storage etc) instead of spending time arguing in threads meant for something else. 

A compromised BCCAPI cannot double-spend. It cannot sign transactions because it doesn't have the keys. It could re-send the same transaction but that is pointless. It could lie to the client about a balance but that is quickly discovered.