Topic: The original Bitcoin client sucks. (Read 5672 times)

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?

Related : https://bitcointalksearch.org/topic/m.1100938

The original post sucks

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

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.

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.

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.

+1 to everything you said in this post. That's how I see it too.

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.

"Why should they?"
Most of them are open source.
Most of them have been around for a while.
Most of them are developed by real well known people where you can look up their home address.
I would pick one that matches the above and that suits my use-case/platform/risk level. Some light/ewallets give you full/exclusive controlover your private keys.

However, I agree that it would be useful to have a listing on bitcoin.org with pros&cons that allows you to make a well informed choice.

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.

hmm.. how about calling it bitcoind 

+∞ This would be actually pretty awesome.

I agree with OP and I think we should be realistic about how it functions and the expectations people have. It's slow to open and becomes unresponsive all the time. The system tray applet is very slow to respond and typically waits so long it wigs out when it finally does get my input (minimize/restore many times)

Let's not let this be seen as a "down with bitcoin" discussion but instead a healthy note about our progress.

I am working on a solution to this problem as we speak.    I agree it doesn't need tools for a average person to get involved.

Dalkore

You make some very good and valid points, but at the same time you omit crucial features.

AOL,CompServe,Prodigy,etc. were:
a) walled gardens
b) vehemently against 3-rd party scripting languages due to their insecurity

Netscape had:
a) military-style maketing campaigns
b) Javascript, as insecure as it was
c) openness

The same tug-of-war is versus safe prison and wild,wild world is right now happening between Apple iOS and Google Android.

I'll let everyone else to make their own analogies with the current state of Bitcoin and the value of the protection they are getting from the helmsmen.

The original plan (Satoshis plan) was indeed that his code would switch to/from lightweight mode as required.

In the end, that plan hasn't happened. The only lightweight/SPV client that exist are based on my code, which was written from scratch. The work that has gone into the reference codebase has primarily been about features, performance and scalability (of fully validating mode).

Anyway, tl;dr - we'll get there. Bitcoin now is kind of like the web was a couple of years after it was created:  complicated, limited, obscure and most people used AOL or CompuServe. Film trailers had AOL keywords in them, not web site addresses. Of course eventually people all switched to the internet/web even though it didn't have the same kind of simplicity and military-style marketing campaigns behind it, because of its inherent advantages.

/preparing popcorn and a frrresh pot of coffee 

~Jompin Alpaca~

wtf?

What we have here is the classic old money/new money split.

Old money wants control and protection of their hard-won assets.

New money wants a toolset to integrate with their means of producing, well, new money.

This will not be easy to reconcille. If you want to see how this worked here look no furter than the recent sidelining of Armory by the use of compressed keys in the wallet.

Old money want protection first of all. Therefore they will push for the almost paranoidal security stance. The best example is the use of the deterministic build system Gitian. This is an exact opposite what a system integrator would need.

Deterministic builders were pretty much discredited long ago, approximately during Star Wars (I'm sorry I meant Strategic Defense Initiative, not the George Lucas' film), then under the name of "Deterministic Ada compilers." But they recently had a revival amongst those unfamiliar with the history of the computer science.

I'm going to predict that the refactoring of the existing Satoshi legacy code will not occur for a long time.