Topic: cbitcoin - Bitcoin implementation in C. Currently in development. - page 5. (Read 20319 times)

Good to know.

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.


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.

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

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.

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.

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.

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.

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

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


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.

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

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.

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.

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

+21 million for valgrind

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.

valgrind is your friend

Thanks... The power afforded by C does sometimes cause problems like this....

It's got even worse since the stack has screwed up. Like here, where the hell did main() go???


Luckily for me, this type of awkward error is rare but when it happens it's horrible.

...Almost certain the root cause is some stack corruption, not heap corruption. Eventually I'll figure it out...

Edit: Figured out what I thought was the problem was actually completely fine... I must be too tired. I will come back to this tomorrow.

Good luck with that.

(thats why i don't code in C, )

I'm very close to alpha stage now but I'm getting horrible heap corruption. Goodness knows how long it will take to debug...

Useless complaining over 4 bytes per block anyway. 

It's certainly faster to be able to do some checks before requiring the parent to exist. This allows you to validate the PoW of received orphan blocks, before bothering to request parent. Also, it allows doing some checks on a received block before needing a lock on the block tree data structure.