Bitcoin Forum

It takes forever to get started and I bet most people who are new to Bitcoin pick it up, get tired of it and move on.

Why hasn't the development team created a thin client yet?

Without the original client we would all be fucked. It is the only fully validating bitcoin node in existence. There are many alternative light clients. Take a look at http://lovebitcoins.org/getStarted.html

I have the odd impression you need to buy something really fast... ? Then don't use the desktop wallet if you're in a hurry!

Servers and miners can run it. Regular, dumb people like me don't care and don't want to bother with it.

If you want Bitcoin to continue to be a small, geek currency, then please keep forcing this slow, CPU-intensive software down our throats.

As for your lite clients, people who type "Bitcoin" in google never learn about them. It took me forever to find http://blockchain.info/wallet because it doesn't get the privilege of being called "official".

I agree. The block chain download is making newbie users hate bitcoin. However there are better alternatives in the pipeline: http://electrum-desktop.com/

And web wallets work pretty well for small amounts IMHO...

The satoshi client is THE reference client - without it there is no bitcoin network.

You can imagine that the devs have to be conservative with any changes they make and make sure everything is tested as best as possible. This inevitably takes much longer to make changes.

By keeping the bitcoin network stable and working smoothly they ARE indirectly helping to create lightweight clients and web wallets etc. Everyone else relies on them. With the limited manpower all open source projects have I presume they concentrate their firepower on "keeping the engine running smoothly" and leave the eye candy to other devs.

I'm pretty sure bitcoin is losing HUGE amounts of users just because bitcoin-qt appears so prominently on google and bitcoin.org. Most normal people usually don't bother 'looking for alternative clients.'

When they try bitcoin-qt and realize it takes many hours (or days!) to initialize, and consumes many gigabytes of bandwidth per month, they just don't bother looking further. Kinda sad.

We know that startup time whilst syncing the chain is a problem. There's no need to bait us - nobody wants Bitcoin to be a small, geek-only currency, certainly none of us on the development teams do.

Lightweight clients have been written. I have spent the last 2 years writing code that is widely used in their creation. If you go to bitcoin.org and click Clients you'll see some of them. In fact Jim, the author of Multibit which is a lightweight client, already posted on this thread. He was just too modest to plug his own software.

So why is the Satoshi client still the version in the top right of the home page? There are several reasons why we're not ready to fully push lightweight clients yet:

• One is that we still need lots of people to run the Satoshi client. Servers and miners are, by themselves, probably not enough right although in the longer term that's definitely the way things will evolve. If not enough people run the reference client we may start to run out of sockets again like we did last year during the wave of press coverage. If we run out of sockets people can't get connected to the network at all.
• The lightweight clients that exist today all have problems of various kinds. Ones based on bitcoinj have various missing features and other things that are considered important (like wallet encryption, though Jim is working on that). Systems like Electrum or the blockchain.info wallet have surprising privacy and security properties that are difficult to explain to people.
• There are changes coming down the pipeline that will dramatically improve the performance of the reference client, dropping chain download time significantly.

I think there's a general consensus right now in the core development team that Bitcoin, in its current state, isn't quite ready to go as a currency for the everyman (or everywoman in your case). It's not just performance. Other parts of the system need work too - it's still too hard to secure your wallet for both end users and service operators, fee handling needs improvement, the software all needs auto update engines. Even basic things like bitcoin: URI handling doesn't work right yet.

So even if tomorrow we redirected everyone to MultiBit or Electrum or blockchain.info from the home page, we would simply swap one set of problems for another. The real solution is to improve all the clients in parallel and then at some point we should be able to build consensus around pushing users towards one or two lightweight clients, whilst simultaneously asking people who have the resources to run the classic client.

Summary: It would be a mistake to prioritize on-boarding new users above all else right now because they'd just hit problems later. The block chain download time acts as a natural throttle on our growth and ensures that anyone who makes it through has the interest and tolerance needed to manage Bitcoins other issues.

I do not really mind the original client to be honest, it does its job and if its kept up to date on a regular basis it doesnt take too long to catch up.
I agree though that new users may be put off.

+1 - I like the original client and I actually look forward to firing it up and watching my payments come in from my deposits as it syncs with the network (yes, I am a total nerd I know). As for it being daunting to new users, I certainly agree that the time needed to download the blockchain can be considered a deterrent but I also can't help but feel that if someone has problems with copying/pasting, typing in labels, selecting from an address book and pressing a send button then maybe that person shouldn't be sending money over the Internets with any method  ;)

From an email I sent to somebody concerned about bitcoin usability just a couple of days ago:

Making the reference Bitcoin application more usable isn't a high priority for me right now.

The high priority is making it safe to use, even if your computer gets infected by malware. I WANT it to be hard and geeky to use so only geeks who are able to keep their computers secure run it.

Also, the "download and run software on my computer" way of doing things is dying. The vast majority of ordinary users will be using Bitcoin on their smart-phones or through a web browser in the near future....

This is a legitimate concern. Perhaps a simple change of wording on bitcoin.org and other prominent sites would help?

Fair enough, but at least put up a "geeks only"-type notice (phrased more politely, of course) on the front page then.
Letting ordinary people waste hours or days of their time on downloading the reference client AND the 3GB blockchain,
without any obvious warning, is a little disrespectful IMHO.

I don't see any reason why we can't have the best of both worlds.  Why can't the Satoshi client operate as a thin client when it's first installed, and then switch to full client mode in the background when the blockchain becomes up to date?

I think some kind of 'warning' or note that the original client is still very 'technical'? could be an idea to point the average user to web-wallets, light-weight clients or mobile clients.

+1

+2, maybe use those checkpoints for something good

Yes, use an alternative client. Just like MT GOX was doing when they sent coins to an invalid address. Seriously, don't do it; the original client is more reliable than something that's been slapped together.

I disagree. There are other thin clients being developed. Satoshi client should remain a full-fledged stable client, it makes no sense to try to appeal to everyone with it.

Thats fair enough, but wouldn´t it be possible to include an up to date snapshot of the current blockchain (updated on a daily/weekly basis), as an option. Whilst the disk space being taken up is substantial the real issue seems to be the time it takes to catch up when first installing the client. Downloading via the network takes for ever. I do get that you may not want to do that via bitcoin.org. but how about providing it via a torrent link for example?

I actually think it makes more sense to build a thin client from scratch than base it on Satoshi client. But of course if you want to implement a thin client, you decide yourself.

Perhaps it would make sense to start calling Bitcoin-Qt a backbone node rather than a "client".

That's pretty much it.  The reference client needs to be correct first and foremost, and that is primarily where the "core dev team" attention goes.

But isn't "core dev team" a meaningless term?  There are many other developers working on web wallets and alternative clients that are far more usable.  At a minimum I would trust the clients built upon BitcoinJ.

Using MtGox or another web wallet means zero blockchain download time, too.

We can!  Get a github account and start submitting pull requests.

It's open source:  if you have a need, we welcome those changes being submitted.  The Qt part of the client certainly needs more Qt hackers!

If you can't program, hire someone who can write the feature for you.

Because the Satoshi client likely SHOULDN'T be used by most users.  As Bitcoin continues to grow and diversify the reference client will increasingly only be used by miners, merchants, service providers, and hardcore (technically capable) users.   Trying to make it light and friendly is counter productive.   The bitcoind portion of the reference client is used by our company (and many others).  The reference client needs to be stable, secure, and provide an example for other implementations.  We should be encouraging DIVERSITY in clients not trying to create the single "uber client"  which is everything to all users.  

While it isn't my call I think three things probably need to happen over time:
1) The reference client needs to stop being called "the bitcoin client".  I use the term Satoshi client or reference client in everyday language.  The developers using the term Bitcoin client creates an implied sense that this is THE CLIENT and increasingly it is the worst choice for new casual users.

2) The satoshi client should be given less prominence on bitcoin.org.  All clients should be considered peers.  The bitcoin.org website should deal with the protocol and provide access to all clients on an equal basis.  Maybe management of bitcoin.org should be handled by someone who isn't involved in the development of the Satoshi client.

3) It would also be useful if the Satoshi client was refactored into three independent components:

* the library (which could be used by other developers to build alternative clients without rebuilding the low end code).  This would prevent a lot of reinventing the wheel and keep various clients on the same core codebase.  A change to the library could be easily integrated into new version of alternative clients. 

* the node - providing high level abstraction of the non-wallet portions of the client.  Has no concept of wallets, user interface, etc.   It receives commands from client(s) and communicates with the network.  Runs as a daemon or windows service 24/7 in the background.  (Note: electrum server is essentially a non-reference implementation of "the node").

* the client/GUI - communicates with a node (either locally or remotely) to facilitate the actions of the user.  Has no direct connection to the bitcoin network instead it sends command to "the node".

Currently the reference client is all three major components tightly integrated together which makes extending it very difficult.  If other developers do extend it for custom implementations it becomes a continually challenge to keep that fork compatible with changes made to the satoshi client codebase.   Tight integration between these major components stifles alternatives and results in a lot of "reinventing the wheel".

I think you mistake the intent of the reference implementation and the nature of bootstrapping an entire social movement. The standard client is needed to run the network and is not needed by casual users to use Bitcoin. Right now, its better to attract the competent who can help build the network infrastructure and services needed to transform Bitcoin into something useful, simple and safe for all users.

yea, this, very much. right now is like the 80'd and early 90's of the internet. building the network and systems so that the really cool, user friendly and poetentiall world changing stuff can more easily be accomplished later. laying a foundation, as it were. as such, the more technically inclined the user base the better, for the time being. at the least, i figure we'd want a "bitcoin 1.0" satoshi reference client before REALLY going into user friendly (read: AOL back in the 90's) territory.

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.
 

wtf?

/preparing popcorn and a frrresh pot of coffee 

~Jompin Alpaca~

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.

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.

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

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.

+∞ This would be actually pretty awesome.

hmm.. how about calling it bitcoind  ::)

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.

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

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

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.

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.

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' (http://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis) 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.

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

The original post sucks

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

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?