cbitcoin - Bitcoin implementation in C. Currently in development.

[MatthewLM]

It would be... if it worked on Mountain Lion. Maybe I should try to run the code on Linux, which I need to do anyway.

[1714923401]

1714923401

[1714923401]

1714923401

[1714923401]

1714923401

[1714923401]

1714923401

[1714923401]

1714923401

[1714923401]

1714923401

[notme]

+21 million for valgrind

[Gavin Andresen]

Does valgrind really not work on Mountain Lion?  Good reason for me not to upgrade... (runs great on Snow Leopard).

[MatthewLM]

No, it's not working properly on Mountain Lion yet.

Never mind for me since I need to ensure my library is working in Linux anyway. The problem I have is trying to get it working smoothly on a virtual machine. This worked nice in the past but the computer is too hungry for RAM now so I really need to upgrade the RAM.

The reason I upgraded to Mountain Lion from Snow Leopard is because Apple wont let you upgrade Xcode otherwise... Well, at least the new mission control and application exposé thing is quite good.

[MatthewLM]

Well valgrind helped me find a few problems... unfortunately not the most annoying one that is keeping me back. I'm also having problems with libev. Does anyone have any experience with it? My current implementation is here: https://github.com/MatthewLM/cbitcoin/blob/master/dependencies/sockets/CBLibevSockets.c

It runs but gets stuck doing nothing.

[MatthewLM]

I figured out that my code was timing out and after I fixed that I'm getting a very strange valgrind error: http://stackoverflow.com/questions/12309178/valgrind-strange-syscall-param-socketcall-sendtomsg-points-to-uninitialised-b

[Remember remember the 5th of November]

If this library will be libevent dependant, it's already not portable, since libevent is hardly found for Windows.

And I also found this bit of code

void CBSecureRandomSeed(uint64_t gen){
   FILE * f = fopen("/dev/urandom", "r"); // Using urandom for speed.
   fread((void *)gen, 32, 1, f);
}

There is no /dev/urandom on Windows.

Though I suppose, since it's still early in development, Windows support could wait, but then again when you add more dependencies which are for Unix machines(I have not seen a port of libevent for Windows, for instance), it will be tough to add Windows support.

[MatthewLM]

Sorry if it is not clear but cbitcoin is not dependent on libevent. The CBNetworkCommunicator code is dependent on a networking library but the dependency is satisfied via the implementation of functions. The implementation may use any networking library providing it can satisfy the requirements of cbitcoin (It also requires timer functions).

cbitcoin by itself is completely standard C99 using nothing but the standard C99 libraries. The dependencies are defined with weak linked function prototypes. You could say that isn't C99 and is a compiler addition, though the library would work by building it with the dependencies as well. The weak linking is done through pragma directives and works with gcc.

Also I thought libevent was available for windows. I understand cbitcoin is not Windows friendly because Windows is not C99 friendly. I don't even have Windows so I will be relying on other people to produce windows compatibility.

At the moment I've tested cbitcoin on OSX Mountain Lion and Linux Mint 13. It works minus the strange problems with the CBNetworkCommunicator code (please feel free to help with this). I've implemented everything even though it's not all properly working so I'll be making an alpha release shortly...

... I think I bizarrely just found the problem I have with the CBNetworkCommunicator... My eyes just saw something and I'm angry that GDB failed to detect it. Watchpoints do not seem to work properly...

[Remember remember the 5th of November]

Windows will be tough, some C applications usually require little to no modification to compile under GCC(Windows) whereas some may be much harder to do.
It really depends on how much OS specific APIs you use.

[MatthewLM]

Well cbitcoin uses no OS-specific libraries, it just requires implementations of some functions. Provided with cbitcoin are solutions that work on Unix/Linux OSes (Tested Linux and OSX) but there is no reason why Windows implementations cannot be written. You can use cbitcoin without implementing those functions but some parts will not work. For example you cannot build and use merkle trees without implementing the SHA-256 function.

I've implementing networking with libevent but I also have an experimental libev implementation which does not work and I do not understand how to get working (If anyone understands libev, please help!).

As for the problems I'm having with the CBNetworkCommunicator code, I've realised the problem is with clashing connections which I forgot I didn't solve properly (the original client doesn't solve this problem but I'm trying to). I've implemented a method for favouring a connection when two clash but I'm getting a few issues with the expected behaviour of getaddr and addr. I'll find the issue and solve it. Then I will release cbitcoin as an alpha release and try to spur some more interest in the project as a result.

[randy-waterhouse]

Have you considered converting to an autotools build format for the library?

I could do this for you .... nb: the src tree structure would probably have to be flattened out (i.e. changed) quite a bit.

[notme]

If this library will be libevent dependant, it's already not portable, since libevent is hardly found for Windows.

And I also found this bit of code

void CBSecureRandomSeed(uint64_t gen){
   FILE * f = fopen("/dev/urandom", "r"); // Using urandom for speed.
   fread((void *)gen, 32, 1, f);
}

There is no /dev/urandom on Windows.

Though I suppose, since it's still early in development, Windows support could wait, but then again when you add more dependencies which are for Unix machines(I have not seen a port of libevent for Windows, for instance), it will be tough to add Windows support.

From http://en.wikipedia.org/wiki//dev/random

A counterpart to /dev/random is /dev/urandom ("unlocked"/non-blocking random source[4]) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random. While it is still intended as a pseudorandom number generator suitable for most cryptographic purposes, it is not recommended for the generation of long-term cryptographic keys.

If this seed has anything to do with the private keys, you really should be using /dev/random.  If it blocks, just have the user wiggle their mouse or ask their cat walk on the keyboard until you get enough entropy.

[MatthewLM]

Have you considered converting to an autotools build format for the library?

I could do this for you .... nb: the src tree structure would probably have to be flattened out (i.e. changed) quite a bit.

I do like the tree structure. I do undertand that doesn't work very well for make files, though you can use bash to copy the files into a temporary directory, no?

Python was the easiest way for me at the moment. Feel free to play with it.

If this seed has anything to do with the private keys, you really should be using /dev/random.  If it blocks, just have the user wiggle their mouse or ask their cat walk on the keyboard until you get enough entropy.

It hasn't got anything to do with private keys. It's to do with the address manager where the security is not that critical.

[notme]

Have you considered converting to an autotools build format for the library?

I could do this for you .... nb: the src tree structure would probably have to be flattened out (i.e. changed) quite a bit.

I do like the tree structure. I do undertand that doesn't work very well for make files, though you can use bash to copy the files into a temporary directory, no?

Python was the easiest way for me at the moment. Feel free to play with it.

If this seed has anything to do with the private keys, you really should be using /dev/random.  If it blocks, just have the user wiggle their mouse or ask their cat walk on the keyboard until you get enough entropy.

It hasn't got anything to do with private keys. It's to do with the address manager where the security is not that critical.

Good to know.

[MatthewLM]

I've released the first alpha version of cbitcoin: https://bitcointalk.org/index.php?topic=109312.0

Everything is implemented. You may notice a lot of bitcoin features are not included. This is because cbitcoin provides the fundamental functions of bitcoin and doesn't try to be specific. It cannot be called a client library (I'll be making a client library later that uses cbitcoin for BitEagle).

I wont make this beta until I'm personally happy with the testing I've done and I've implemented BitEagle on top of it. By implementing the client software on-top it will allow me to detect problems. BitEagle is the codename for the client which is in the conceptual stage at the moment.

I figured out how to use the git branches (I think) so I'll use the alpha branch to make fixes to the 1.0 release and the master branch will be for new features etc. for new releases.

[grondilu]

I'm not sure I will ever succeed to do this, but I will try to make a Perl6 interface to this library, using the NativeCall module.   If anyone wants to help, please PM me.

[grondilu]

To compile your libraries on my 32-bits, debian GNU/linux host, I had to change line 94 of BUILD.py (why not use a makefile, btw?):

Code:

cflags += " -m64"

into:

Code:

cflags += " -m32"

Also, in src/structures/CBBigInt/CBBigInt.c, line 43:

Code:

	for (u_int8_t x = a.length - 1;; x--) { 

into:

Code:

	for (uint8_t x = a.length - 1;; x--) { 

Then all compilation seems fine, but linking fails:

LINKING ./build/bin/libcbitcoin.so
gcc: error: unrecognized command line option ‘-flat_namespace’


I just removed this option and linking succeeded.  Hope it's ok.

[MatthewLM]

I'm not sure I will ever succeed to do this, but I will try to make a Perl6 interface to this library, using the NativeCall module.   If anyone wants to help, please PM me.

Good luck with this. If you have any questions about the library just send an email to cbitcoin@thelibertyportal.com And keep in note it's still in alpha and probably has all sorts of problems some of which are known already (CBNetworkCommunicator has issues).

To compile your libraries on my 32-bits, debian GNU/linux host, I had to change line 94 of BUILD.py

I should have a 32bit option in there.

why not use a makefile, btw?

The reason I don't have a makefile is because it's not a trivial thing to compile and I'm not good with makefiles. A makefile would be nice be it's not something I want to produce right now. Anyone is highly welcome to create a makefile however. I do ask that the tree structure of the source and header files remains intact, so you'd need some sort of bash code to work through that (One thing that made me use python instead).

Thanks for spotting the u_int8_t problem in the master branch. I've fixed that.

The flat_namespace problem should also be fixed for both the alpha and master branch.

[MatthewLM]

Does anyone understand the RAND_add OpenSSL function. How do I figure out what to pass into the entropy argument? I literally have no clue, the docs are terrible. I'm adding entropy from a text string given through the terminal eg. dskjbapohspigpivsbvo98sg2pib3r2oivbspvow48fiqpbfivbsv=s like a monkey on a type-writer.

[misterbigg]

Just use OpenSSL for bignum and move on.

OpenSSL is a giant pain in the ass to build.

My preference for a repository is that everything compile by just pushing a button. No external dependencies (especially "wget", ick). It should not be necessary to install anything else. No python, no separate repositories, etc...

If I use an external dependency then I bring it in to my repository using "git subtree", which makes it very easy to work with. Sometimes I produce amalgamations of external libraries to make them easy to integrate (for example, I have produced an amalgamated version of FreeType).

If someone is better at C than C++ I have to question their proficiency in general. Learning new languages is part of being a good programmer.

This having been said, the GPL is the kiss of death for this project. It is an encumberance that virtually assures that cbitcoin will never become serious to corporations.

For some examples of git subtree and amalgamations, have a look at the repositories in my signature.