Best independent client?

[jim618]

@The_Duke

From your posts you mention that you are:

1) a dev
2) clearly passionate about Bitcoin's future
3) already contributing to not-for-profit bodies

You are thus the ideal candidate to work on a bitcoin client/ server !

As far as I know that are 3 projects that are working in this area:

1) cbitcoin - written in C, primarily focused on embedded systems
2) libcoin - written in C++, designed to be a fully verifying node (eventually)
3) Matt Corallo has done a fair amount of work in extending bitcoinj to be fully verifying. (Java)

Take your pick.

To quote Terminator:

"There is no fate but what we make"

[The_Duke]

@The_Duke

From your posts you mention that you are:

1) a dev
2) clearly passionate about Bitcoin's future
3) already contributing to not-for-profit bodies

You are thus the ideal candidate to work on a bitcoin client/ server !

I wouldn't quickly call myself ideal, but I'd probably be an option yes. There's limits of course on how much a person can do though. It would mean saying goodbye to at least one of my current projects, since I don't want take more time away from my family.
Since the other two projects currently serve a lot more people than bitcoin does, that'd be a difficult choice. Bitcoin has great potential though, so it's on my mind...

As far as I know that are 3 projects that are working in this area:

1) cbitcoin - written in C, primarily focused on embedded systems
2) libcoin - written in C++, designed to be a fully verifying node (eventually)
3) Matt Corallo has done a fair amount of work in extending bitcoinj to be fully verifying. (Java)

Number 1 would be very close to my field of work, so I could probably contribute some. I like the "fully verifying node" part of Nr. 2, and C++ is also manageable for me. As for nr3, with no disrespect meant to Mr. Corallo, I hate Java.

I've understood your point though. If it doesn't exist, contribute to it yourself. And I might, it's a good thought in any case.
However, there's many things in life that I think can be improved, created, started or changed. "Do it yourself" can never be the answer to all of them of course. In most cases, we'll have to rely on other people doing the work and can only hope to make our voice heard.

[MatthewLM]

hint, hint, cbitcoin is ready to be used... it's a library not a client though.

Is it? I've checked in there a few times and thought it was still very early and not far enough along. Is there any info on how it compares to bitcoind and whether it saves space or can do SPV?

Well that's just what I've been picking up when the thread popped up. There was something about it being fully or at least sufficiently featured by now in the last update. I don't know any specifics.

cbitcoin (http://cbitcoin.com) is in alpha stage. This means it is probably has many issues. Feel free to experiment with it and contribute to it's development but I do not recommend using it for any applications yet.

1) cbitcoin - written in C, primarily focused on embedded systems

cbitcoin isn't primarily focused on embedded systems. I only stated that the code could probably be adapted for embedded systems. It's designed with focus on portability and efficiency (Though I've not yet worked on optimisation yet) and it is currently a low-level library with many core bitcoin features. It doesn't contain everything you need for a fully validating client. Expect some announcements on cbitcoin in the upcoming weeks about the direction I plan to take it.

Number 1 would be very close to my field of work, so I could probably contribute some.

Anyone is very welcome to contribute code. The github repository is here: github.com/MatthewLM/cbitcoin and the documentation (incomplete and maybe inaccurate in areas) is here: http://cbitcoin.com/docs/index.html

[jgarzik]

Correct me if I'm wrong but I believe all clients still depend on bitcoind. That is, the essential part of verifying and storing the blockchain and communicating with other clients is still handled in all clients by this one backend codebase. I may be wrong here as I have not checked all the clients myself.

This is incorrect.

BitcoinJ, pynode and ufasoft-coin do not depend at all on bitcoind.  Other alternate implementations also exist, in varying states of completion (bitcoin-alt, purecoin, ...)

[flatfly]

Correct me if I'm wrong but I believe all clients still depend on bitcoind. That is, the essential part of verifying and storing the blockchain and communicating with other clients is still handled in all clients by this one backend codebase. I may be wrong here as I have not checked all the clients myself.

This is incorrect.

BitcoinJ, pynode and ufasoft-coin do not depend at all on bitcoind.  Other alternate implementations also exist, in varying states of completion (bitcoin-alt, purecoin, ...)

I guess it depends what you mean by "depends on"

Their code doesn't depend on bitcoind in the classical sense, but as far as I know, they do still depend on
it because they are not full-verifying nodes, so a network without bitcoind nodes to connect to can't operate properly (correct me if I'm wrong).

 

[jgarzik]

Their code doesn't depend on bitcoind in the classical sense, but as far as I know, they do still depend on
it because they are not full-verifying nodes, so a network without bitcoind nodes to connect to can't operate properly (correct me if I'm wrong).

pynode and ufasoft-coin are full, verifying nodes.  purecoin is too, I think, as is mtve's Perl bitcoin implementation.

The full nodes actually on the network are still 98% reference client (bitcoind).

[The_Duke]

Their code doesn't depend on bitcoind in the classical sense, but as far as I know, they do still depend on
it because they are not full-verifying nodes, so a network without bitcoind nodes to connect to can't operate properly (correct me if I'm wrong).

pynode and ufasoft-coin are full, verifying nodes.  purecoin is too, I think, as is mtve's Perl bitcoin implementation.

The full nodes actually on the network are still 98% reference client (bitcoind).

But if all bitcoind clients would go offline tomorrow, the other 2% would continue the network, right? (I understand how weak and vulnerable that network would be though)

In that case, I will be switching to an alternative client out of the few you mentioned somewhere next week. (Need some time to browse through the code and do some research). That 2% needs to be increased imho for the good of bitcoin.
Thank you for the answers Jeff, much appreciated.

[flatfly]

Their code doesn't depend on bitcoind in the classical sense, but as far as I know, they do still depend on
it because they are not full-verifying nodes, so a network without bitcoind nodes to connect to can't operate properly (correct me if I'm wrong).

pynode and ufasoft-coin are full, verifying nodes.  purecoin is too, I think, as is mtve's Perl bitcoin implementation.

The full nodes actually on the network are still 98% reference client (bitcoind).

Thanks for clarifying that.
As for BitcoinJ, I thought I read somewhere that it wasn't a full node at this time but might become one in the future. Can't find that post right now, though...

[jgarzik]

As for BitcoinJ, I thought I read somewhere that it wasn't a full node at this time but might become one in the future. Can't find that post right now, though...

Correct.  BitcoinJ is primarily focused on lightweight client mode, but BlueMatt has been working on adding the necessary verification code.  Not there yet, though.