The original Bitcoin client sucks.

[DeathAndTaxes]

The high priority is making it safe to use, even if your computer gets infected by malware.

I don't see how can that be possible without the use of a "uninfectable" dedicated device to sign the transactions.

That quote refers to multi-sig implementation where one of the two private keys are on a second device (like say mobile phone).  Compromise of funds would require finding and compromising two independent devices.  It would raise the bar significantly.

[niko]

The high priority is making it safe to use, even if your computer gets infected by malware.

I don't see how can that be possible without the use of a "uninfectable" dedicated device to sign the transactions.

I wouldn't even say strong security to non-tech users should be a priority of the reference implementation at all. Leave that to clients like Armory. The reference implementation should focus on the protocol, IMHO.

Yes, I agree. However, prominent Web sites such as bitcoin.org should be carefully written with a new user in mind. Perhaps a word of warning about the blockchain size, and a list of available alternative thin  (and thick) clients. Online wallets should be mentioned, but not listed/endorsed due to trust issues.

[jim618]

I think it is a matter of trust - average users might trust the bitcoin.org client (because it's by far the oldest and most popular) but not trust other light clients not to steal all their money - and why should they?

Perhaps bitcoin.org should host a trusted version of a light client.

One of the reasons why I have been working on getting AES encrypted private keys into MultiBit (it's in test at the moment) it that it helps here.

Imagine a 'rubber hose attack' i.e. someone threatens me and says 'Put a backdoor into MultiBit or we shoot your family'.

When the encrypted wallets goes into MultiBit you can then have:

+ AES encrypted private keys where there is no record - except with the user - of the password.
+ Multiple wallets e.g. a daily use wallet, savings1, savings2 etc.
+ You encrypt all of your private key export files. This is recommended practice - there is a warning message if you export unencrypted.
+ Perhaps you also keep a copy of MultiBit with a wallet on a USB stick so that it is not even online 99.9% of the time.
+ There is an extremely gossipy user base that will flash out any wallet stealing action that occurs.

These elements collectively give an element of protection.

The only time MultiBit could steal your BTC from an encrypted wallet is after you type in your password (so that the private keys can be decrypted and a 'steal transaction' can be signed.).
Say you upgrade to the hypothetical Trojan MultiBit and open your daily wallet and enter your password. You are unlucky enough to be the first person who does this and your BTC get stolen.

You then tell everyone - this will happen virtually instantly. Noone will download the trojan MultiBit. (This is the reason there is no auto-update too actually).

In this scenario your rarely used savings wallets the Trojan cannot decrypt the private keys (assuming you have used a different password from your daily wallet - you have to take reasonable precautions).

It is not perfect but hopefully the low chance of it actually working in practice makes this sort of attack not worth bothering with.

[unclemantis]

I gave up on thin clients and just settled on a cold wallet and bitcoin-qt, and keep my computer on all the time. I also installed bitcoin-qt on two other family computers just to keep the network working faster, I hope

[softwareseller]

The original post sucks

[Transisto]

Related : https://bitcointalk.org/index.php?topic=100779.msg1100938#msg1100938

[zveda2000]

In the case that we will be doing a hard-fork at some point in the future, in order to increase the number of transactions-per-second for example, would it make things easier if a larger number of people were on thin clients like electrum? We know it is very hard to get people to update to the newest version of bitcoin-qt. Perhaps if bitcoin-qt is only run by geeks and miners and such, a hard fork might be easier to do? Or will the hard-fork also cause a fork for all of the thin clients as well?