I don't like Gavin's and Jeff's Bitcoin client - can I write my own?

[BalkanBoy]

So I woke up one morning and decided I don't like Gavin's and Jeff's bitcoin clients for any of the platforms.

Can I write my own, and is there anything technically stopping me from doing this if I were to follow the rules of trading/transactions on the Bitcoin network?

Maybe I want to write a Haskell or a Clojure client... or Ruby. Is there anything stopping me from writing one and getting other people to use it if they see value in it?

Where is the protocol specified of how to write a Bitcoin client/daemon?

Thanks!

[Garrett Burgwardt]

Nothing to stop you, you'll want to talk to Mike Hearn, he's a google dev working on bitcoinj, he can help you more than I can.

Design something awesome! I'd love to have a solid alternate client!

[lizthegrey]

A friend and I are about to start a Python partial implementation.

[riX]

Of course, but you need to be very careful to get everything right and secure.
I'm sure it's not the client you don't like, but the GUI.
Maybe you can change what you don't like and publish some patches for the official client.

[goatpig]

Of course, but you need to be very careful to get everything right and secure.
I'm sure it's not the client you don't like, but the GUI.
Maybe you can change what you don't like and publish some patches for the official client.

This. If it is GUI related, you can just isolate the core classes and put your GUI code in a seperate file, will make it even easiers for others to adopt it. If you want to change part of the core code, that's another story altogether.

[riX]

This. If it is GUI related, you can just isolate the core classes and put your GUI code in a seperate file..

Or just make a GUI as a front-end for bitcoind, no need to edit the original code at all, just send API commands to the daemon.

[goatpig]

This. If it is GUI related, you can just isolate the core classes and put your GUI code in a seperate file..

Or just make a GUI as a front-end for bitcoind, no need to edit the original code at all, just send API commands to the daemon.

I like the idea but you'd depend on bitcoind for portability.

[PabloW]

You should include a backup button or something. More noob friendly maybe

[wumpus]

This. If it is GUI related, you can just isolate the core classes and put your GUI code in a seperate file, will make it even easiers for others to adopt it. If you want to change part of the core code, that's another story altogether.

Yes, this is how I've done it in bitcoin-qt: https://github.com/laanwj/bitcoin-qt/

I link to the core (with some minor compat changes) as a kind of library.

Currently it mimics the wx bitcoin client. If you want to improve the GUI, pull requests are welcome I'll only start integrating them though when the core functionality of the GUI is finished.

For core changes I recommend improving the core instead of making your own client implementation. A new implementation is a lot of (wasted) effort and it will be difficult to exactly compatible with the current code, any error could result in forks of the chain...

[twmz]

This. If it is GUI related, you can just isolate the core classes and put your GUI code in a seperate file..

Or just make a GUI as a front-end for bitcoind, no need to edit the original code at all, just send API commands to the daemon.

That is what I am doing for my web-based frontend.  The web server (not the web browser) makes JSON-RPC calls to the bitcoind daemon.

[jon_smark]

So I woke up one morning and decided I don't like Gavin's and Jeff's bitcoin clients for any of the platforms.

Not only you can in theory, but also in practice I suspect both Gavin and Jeff would actually welcome multiple independent implementations of the protocol, since that's a good way for any potential vulnerabilities to be found and fixed.

In other words, go forward!

[Gavin Andresen]

Not only you can in theory, but also in practice I suspect both Gavin and Jeff would actually welcome multiple independent implementations of the protocol, since that's a good way for any potential vulnerabilities to be found and fixed.

In other words, go forward!

Yes, diversity is good. If you do decide to go for it, do lots of testing on either the test network or with a testnet-in-a-box setup before even THINKING about handling real bitcoins. If you screw up and lose other people's money it will take a long time to earn back their trust.

Oh, and speaking of trust... unless you have a recognized Brand Name, I don't think you'll have any success with a closed-source client.

[lizthegrey]

Yes, diversity is good. If you do decide to go for it, do lots of testing on either the test network or with a testnet-in-a-box setup before even THINKING about handling real bitcoins. If you screw up and lose other people's money it will take a long time to earn back their trust.

What are peoples' thoughts on creating a compliance test suite for Bitcoin separate from the existing C++ client, and ensuring that both the existing C++ client and new clients (e.g. bitcoinj, bitcoinp) pass the suite?

[xf2_org]

Not only you can in theory, but also in practice I suspect both Gavin and Jeff would actually welcome multiple independent implementations of the protocol, since that's a good way for any potential vulnerabilities to be found and fixed.

And the other developers   I dislike the thread title, because I am but one of a herd of core devs under our lead dev, Gavin.  It's either "Satoshi's client" or "the People's FOSS client" or "Gavin's client" or "Gavin/tcatm/sipa/BlueMat/jgarzik's client"........

[genjix]

Sure you can:

Check out the bindings we made for several languages:
https://gitorious.org/freecoin/freecoin/trees/master/bindings

Also you can as others mentioned use the RPC api to write your own client as we've done here:
https://gitorious.org/freecoin/spesmilo

Or you can write your own implementation of the Bitcoin protocol as we've done too:
https://github.com/phantomcircuit/bitcoin-alt

[lizthegrey]

Or you can write your own implementation of the Bitcoin protocol as we've done too:
https://github.com/phantomcircuit/bitcoin-alt

What is the license on bitcoin-alt?

[Luke-Jr]

Or just make a GUI as a front-end for bitcoind, no need to edit the original code at all, just send API commands to the daemon.

This isn't practical. Spesmilo does it, but it's retardedly inefficient due to the poor design of JSON-RPC.

I dislike the thread title, because I am but one of a herd of core devs under our lead dev, Gavin.  It's either "Satoshi's client" or "the People's FOSS client" or "Gavin's client" or "Gavin/tcatm/sipa/BlueMat/jgarzik's client"........

bitcoind and wxBitcoin are sensible names.

As a core developer of Spesmilo, I'd be interested to see more node/wallet implementations

[gigitrix]

Just want to put my 0.02 BTC in and say go for it! I really want to see a bit more decentralisation when it comes to this stuff, and I'd love it if there were multiple clients. The net gain from having such diversity is far greater than the net loss of dividing our valuable developers tbh

[Mike Hearn]

A C++ regression suite would be really, really useful to have. Though it's quite hard to do effectively because the protocol is so minimal - it's not possible, for example, to find out if a node accepted your block or tx except by doing some rather indirect tricks or using JSON-RPC which makes it only work for the C++ impl.

I think the right way to start is with C++ unit tests and if there are clear cut-lines for a regression suite, implementing that later. Making Bitcoin truly testable means some pretty serious refactorings, eg, introducing a BitCoinJ style NetworkParameters abstraction so you can test on super-easy chains.

[matonis]

Bram Cohen's client for BitTorrent is not the leading client for downloading content from the Internet today.