Topic: cbitcoin - Bitcoin implementation in C. Currently in development. - page 4. (Read 20296 times)
October 01, 2012, 02:57:27 PM
The GPL is a serious problem? For some people maybe. For me? No.
October 01, 2012, 05:55:15 AM
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.
September 30, 2012, 11:46:33 PM
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.
September 30, 2012, 01:15:27 PM
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.
September 30, 2012, 10:49:57 AM
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.
September 30, 2012, 09:56:55 AM
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. :-)
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. :-)
September 30, 2012, 05:57:15 AM
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.
September 29, 2012, 01:01:27 PM
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.
September 29, 2012, 12:57:56 PM
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).
September 29, 2012, 12:51:48 PM
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".
September 29, 2012, 12:28:57 PM
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.
September 29, 2012, 12:28:51 PM
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.
September 29, 2012, 12:25:30 PM
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?
September 29, 2012, 11:58:37 AM
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.
Quote
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.
Quote
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.
Quote
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.
September 29, 2012, 11:30:23 AM
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.
September 29, 2012, 11:18:45 AM
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.
September 29, 2012, 10:45:40 AM
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 [email protected] 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).
Quote
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.
Quote
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.
September 29, 2012, 09:01:58 AM
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?):
into:
Also, in src/structures/CBBigInt/CBBigInt.c, line 43:
into:
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.
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.
September 29, 2012, 08:39:19 AM
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.
September 13, 2012, 06:38:23 PM
I've released the first alpha version of cbitcoin: https://bitcointalksearch.org/topic/ann-cbitcoin-10-alpha-4-released-109312
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.
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.
Jump to: