Shortage of bitcoin clients?

[firepacket]

Bitcoin has been around for some time now and yet there seems to be only one legitimate competitor (armory) to the main bitcoin client and even that requires keeping the main client running for full functionality.

Instead of worrying about things like address management, wallet files, bootstrapping, gui, etc why cant the main client devs focus on making a multi-platform library that can be imported by everyone else? Thinks like reading the blockchain, transactions, p2p protocol and much more would obviously need to be handled by a core library. But I think many other implementation details can and should be left up to individual devs. Not only will this turn bitcoin into a true *platform* for development, but it would lead to specialized clients that can fulfill niche roles not yet foreseen.

Right now I feel bitcoin seems to be held back by its client. Thoughts?

[1713470553]

1713470553

[1713470553]

1713470553

[1713470553]

1713470553

[Red Emerald]

I don't see a problem...

There is a whole subforum devoted to alternate clients: https://bitcointalk.org/index.php?board=37.0

There is also a wiki page: https://en.bitcoin.it/wiki/Software#Bitcoin_clients_2

A few of the clients currently require bitcoind, but that is just because they are still being heavily developed.

libbitcoin is a multi-platform library exactly like you are asking about.

[bitsforcoins.com]

You missed Multibit and Electrum, btw.

[firepacket]

Multibit looks pretty decent, but I notice it is based on bitcoinj written by Google. And libbitcoin is not complete. It still doesnt make sense to me that the bitcoin devs would focus on a full fledged client which is just ONE implementation of what should be an entire platform.

[Forp]

It is Open Source software. So move ahead and contribute a client of your own. That is the solution. :-)

[Kranke]

He doesn't want to build a client, he wants to redesign bitcoind to be a module that can be added to like other OOP.
Does linux have Visual Basic?

[Forp]

I wouldn't do this in a "Visual *" or in a "* Basic" type of language.

You should check out libbitcoin. I studied the source and they are using modern and modular c++ concepts. IMHO this is the way to do it. Also their approach to asynchronous communication and concepts like continuations / completions / futures is very nice.

That said, I think Bitcoin (the reference implementation) is too complicated for an OOP module approach to produce working and correct algorithms unless we do a major refactoring of the code base - and here probably a reimplementation from scratch is the best thing.