cbitcoin - Bitcoin implementation in C. Currently in development.

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

Well keyboard input is not the best source of entropy so I'm using dev/random. This is just for the addressGenerator example program.

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

cbitcoin compiles with no external dependencies, only the standard C library. However it requires that you implement functions when you use the library through weak linking.

Learning new languages is part of being a good programmer.

And what there is no point in learning a new language? It's just a waste of time then. I don't like C++ at all. It annoys me. Unfortunately I have no choice but to read the C++ bitcoin code to help with my code.

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.

I'm not interested in corporations that want to mix my project with their own copyright restricted software. I'm using a "copyleft" license for a good reason.

[grondilu]

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

I'm surprised by this.  I mean, openssl might be hard to use and to link, but what's the alternative exactly?  Reinventing the wheel each time you do some code with cryptography?

[misterbigg]

I'm surprised by this.  I mean, openssl might be hard to use and to link, but what's the alternative exactly?  Reinventing the wheel each time you do some code with cryptography?

Unfortunately, there is no alternative. I haven't had a need for OpenSSL in any of my projects. I tried to amalgamate it for a friend of mine but there's no chance of that happening, the code base is too difficult to work with.

[jgarzik]

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

I'm surprised by this.  I mean, openssl might be hard to use and to link, but what's the alternative exactly?  Reinventing the wheel each time you do some code with cryptography?

Yeah, it is silly and not realistic for any large software, because your maintenance effort scales up to involve tracking $N third party repos for security fixes and other updates.

When Fedora or SuSE Linux distros push out zero-day fixes for OpenSSL or zlib, for example, your project remains vulnerable.

[grondilu]

Unfortunately, there is no alternative. I haven't had a need for OpenSSL in any of my projects. I tried to amalgamate it for a friend of mine but there's no chance of that happening, the code base is too difficult to work with.

That's quite ironic for someone who just wrote:

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.

I mean, for a good programmer, learning how to reuse existing code seems to me at least as important as learning new languages.

Lots of people link their code to the openssl libraries.  They might be complaining about the process being painful, but in the end they eventually do it.  They don't say:  "nah screw this, it's just too difficult".

[misterbigg]

Lots of people link their code to the openssl libraries.  They might be complaining about the process being painful, but in the end they eventually do it.  They don't say:  "nah screw this, it's just too difficult".

I said it was too difficult to amalgamate (https://github.com/vinniefalco/Amalgamate).

[grondilu]

I said it was too difficult to amalgamate (https://github.com/vinniefalco/Amalgamate).

Ok.  My bad.   I did not know about this concept.  I guess it's kind of a recent technique and openssl being quite an old library, it might not fit well into it.

[grondilu]

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

Still, it would be great if we could compile your library with a classic "./configure && make"

I'm not good enough a GNU programmer, but if someone here is, please help.

Meanwhile, I'll read the automake manual and I'll see what I can do.

Anyway your project really seem like an awesome step towards a GNU version of bitcoin (C language + GNU license).  Please keep up.

[MatthewLM]

Thanks grondilu. If you or anyone else can help create a Makefile that would be excellent. It might be best to create a fork of cbitcoin on github for this task and when it is completed a pull request can be made to the master branch. This is a good idea even if you cannot get it to work since others may be able to modify it and get it to work.

And yes I'll keep it up the best I can. I've been thinking about how the plans for this project can be improved and I hopefully I'll be able to announce these improvements in the next few weeks when I have everything sorted. If anyone has any suggestions it's a good time to give them to me now. :-)

[wabber]

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.

So someone who doesn't like C++ and prefers to use C is a bad programmer? Well I prefer C.

[misterbigg]

So someone who doesn't like C++ and prefers to use C is a bad programmer? Well I prefer C.

No but disregard my comment, I see why the decision was made, thanks to all for providing their insights.

[deadserious]

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.

Agree 100%.  And not only limiting for corporations.  Even freeware, public domain, small independent but commercial software will be hindered by this.  LGPL I might understand, but GPL?  That's a serious problem.

[grondilu]

Agree 100%.  And not only limiting for corporations.  Even freeware, public domain, small independent but commercial software will be hindered by this.  LGPL I might understand, but GPL?  That's a serious problem.

The linux kernel is under GPL.  That did not prevent Google from using it with Androïd.

Also, if they don't want to use cbitcoin because it's GPL, at least the very existence of cbitcoin will show them it's possible to port bitcoin into C.  So they'll rewrite their own C code.   That's good enough to me.

[MatthewLM]

The GPL is a serious problem? For some people maybe. For me? No.

[notme]

The GPL is a serious problem? For some people maybe. For me? No.

Don't mind the freedom haters.  It's your code, license it how you'd like.

[deadserious]

Agree 100%.  And not only limiting for corporations.  Even freeware, public domain, small independent but commercial software will be hindered by this.  LGPL I might understand, but GPL?  That's a serious problem.

The linux kernel is under GPL.  That did not prevent Google from using it with Androïd.

Linking to anything GPL requires your code to also be GPL (or license compatible).  That means that you cannot link to the library without your software also being open source. For me to use cbitcoin I would have to compile it as an EXE and then use it by calling out to the process. 

That is why many library developers chose to go with LGPL. It allows you to link to the open source code and protect your source code.  If we changed or improved upon cbitcoin in any way, those changes would still have to be made public.

[deadserious]

The GPL is a serious problem? For some people maybe. For me? No.

It is your problem if you hope this to have any serious adoption. 

If you are intending to keep it small, niche and useless to a vast portion of the community that would use it, then no, I guess it's not your problem.

[jgarzik]

That is why many library developers chose to go with LGPL. It allows you to link to the open source code and protect your source code.  If we changed or improved upon cbitcoin in any way, those changes would still have to be made public.

+1

Most libraries are LGPL'd or similar.

A GPL'd library requires that all users be GPL'd.

[MatthewLM]

That means that you cannot link to the library without your software also being open source.

Yes, that's the point.

If you are intending to keep it small, niche and useless to a vast portion of the community that would use it, then no, I guess it's not your problem.

Well grondilu pointed out the linux kernel. That's not exactly "small, niche and useless to a vast portion of the community that would use it".

[kokjo]

woohoo!!! licence flame war incomming!