The original Bitcoin client sucks.

[kangasbros]

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

I know what you mean, but it's still possible to create a new client based on Satoshi client…

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.

[1713300992]

1713300992

[1713300992]

1713300992

[1713300992]

1713300992

[1713300992]

1713300992

[1713300992]

1713300992

[flatfly]

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

[jgarzik]

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.

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.

[jgarzik]

I don't see any reason why we can't have the best of both worlds.

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.

[DeathAndTaxes]

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?

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

[bg002h]

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?

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.

[arklan]

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?

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.

[2112]

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

* the library
* the node
* the client/GUI

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.
 

[kjj]

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

* the library
* the node
* the client/GUI

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

[JompinDox]

/preparing popcorn and a frrresh pot of coffee 

~Jompin Alpaca~

[Mike Hearn]

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.

[2112]

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.

[Dalkore]

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.

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

[kayrice]

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.

[ShadowOfHarbringer]

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?

+1

+2, maybe use those checkpoints for something good

+∞ This would be actually pretty awesome.

[Jan]

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

hmm.. how about calling it bitcoind 

[barbarousrelic]

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.

[Jan]

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.

[caveden]

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.

[caveden]

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.  

....

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