Topic: Proposal for a C bitcoin library. (Read 8366 times)

Is anyone about today maybe interested in a bitcoin C library?

A "libbitcoin" written in C would be very nice, in my opinion.

libbitcoin is a long term goal of the dev team, though it is more likely to be in C++ than C.

I've never used Java before but I am interested in it because I want to look into Android.

Anyone capable of porting java?  

There was a thread complaining about floating point safety. Floating point numbers aren't always accurate and can't represent numbers like decimal can, past the point. If integers can be used instead, I'm all for that. 

A bitcoin specification document should (well I think it's a good idea) be produced with pseudo-code examples or examples in a high level "safe" language.

I'm aware of that project, but that's not the code I'm concerned about (sending coins). The reference implementation would be for validating transactions and the blockchain.

As I see it, the validation of tx is non-trivial (because of the Script functionality which we really don't use, for example). What happens if two implementations have a subtle difference? We'll have a split blockchain. In theory we would have to read satoshi's paper to decide who's on the right, but in practice the "official" implementation will prevail. At the moment, the oficial client is the law. And the law is written in C++, which concerns me.

We trust the core dev team to do the right thing. But I don't want to have to trust them.

C++ is a tool for speed, the functional languages are tools for correctness. We have no need for efficiency in the reference implementation, but of clarity, which will bring trust, which is what money is about. Trust in crypto in the case of Bitcoin.

Also if it depended on me I would freeze the specification now that we still can for only the types of transaction that people actually use. Fuck IP transactions, we don't need all that cruft. Keep it simple. Confidence in Bitcoin would be devastated in case of a technical failure. No more sripts besides the standard one. The only used they've had to date is to attempt buffer overflows. Fuck that. Satoshi made the script language non-turing complete for that reason, but even if it is a cool feature I think he should have skipped it altogether.

This way I can write simple code and know that it won't fail.

I can't write my own implementation of Bitcoin because I *KNOW* it is so complex, it will differ somehow from the official one.

I don't know if I'm getting my point accross.

For anyone who isn't aware of the Java bitcoin libraries:
http://code.google.com/p/bitcoinj/updates/list

I'm sure bitcoin is complex enough for someone to write a book on it. 

Lots of platforms and architectures support C++ but not as much with microcontrollers. And it's harder for C programmers to make use of C++ code. C is one of the most popular languages. C++ programmers can easily take C code, doesn't work the other way around.

Once again, I would love to make a C library but I don't like C++ and there isn't a specification for bitcoin I could use without reading the source code, is there?

Also, I think I'm out of my comfort zone with bit coin.

Don't most platforms that support C also support C++ these days?

Then again, feel free to make another client implementation.

Edit: maybe it would be an idea to write the "business logic"/rules of bitcoin in a very high-level language, that can be interpreted in or converted to  any language you want. This would make it easier to implement bitcoin in other languages, and at the same time make it possible to have a common spec.

Edit2: Another advantage of this would be that you'd be able to support multiple different chains with different rules, switching to new chains potentially without recompiling.

As I said, I personally would be willing to implement it in objective-C. Objective-C is based on C and you can use C99, ANSI etc. with it perfectly.

Can't do that as the source code is now.

My point is that a standard C library would make bitcoin more portable for programming. It would make implementing bit coin on more platforms easier.

I still don't see the use case for the embedded C library, but I'd recommend that you start with a list of platforms you are interested in running it on (and willing to build and test against) then implement, instead of "writing it in stadard C".

I don't use Objective-C++, I hate the existing code and wouldn't know where to start implementing an alternative UI with the tangle of the current code.

A C library would do wonders for helping programmers make use of it.

Reimplementing Bitcoin in C or Objective-C isn't necessary for an iOS version. You could reuse the existing code with some pretty hefty modifications (eg, to not store the chain headers in RAM).

However this is a fairly pointless project right now because Apple have rejected Bitcoin in the past. It'd be a large amount of work to build a nicely running mobile client and there's a high risk of arbitrary rejection. The efforts are better spent elsewhere.

Proposals are, I'm afraid, fairly cheap when it comes to Bitcoin. What matters is working code. Don't underestimate the size of the task. Bitcoin doesn't look like a large codebase, but it's larger than you think due to the way the code is laid out and the code is extremely complex.

There's not much point in making a direct transcript into another language, it'd have to work in some reasonably different way to be useful, so you need a fluent understanding of Bitcoin. Unfortunately it isn't really possible to get fluency today unless you already know C++. The documentation is much better than it used to be, but some details are still non-obvious without reading the code.

You might want to discuss concrete implementations in the "alternative clients" section.

just walking in the topic...
 

@bluecmd: Very nice. I took a look at what has been done. The one conflict with my idea is the platform incompatibilities. You have so far been implementing the network side of bitcoin which is platform-specific.

I do think it would be best to create a core library which is standard c and then allow the programmer using the core library to add platform-specific code with delegate functions. There could be UNIX, Windows, whatever libraries built on top of the core library. A layered approach would increase the portability of the underlying layers.

From what I can tell, the main things which standard c can't provide and that bit coin need are threads and sockets. Am I right? It can't be too difficult for the user of the core library to add delegate functions which provide basic interface to threads and sockets.

Unfortunately the help I can give is limited since I do not understand bitcoin technically and doubt I ever will. Being good with C++ would help me understand the current source but I'm not good with C++. I may be able to aid in certain areas.

@mrenouf: A Java implementation would be good. Of-course a C library could still be used on Android with the NDK and the machine code should handle the performance intensive parts of bitcoin better. But a Java implementation in general would be great for many people I'm sure. Not for my iOS apps since I use Objective-C for that. Please don't port it back to C++ though! 

I will be glad to make Objective-C classes based on a C library if one was made, as I said. Then I can easily make bitcoin applications for Mac and iOS.

For what it's worth, I'm actively porting the BitCoin source to Java.

I plan to produce an Android BitCoin app, but this will also make it easy to develop additional webapps and other services. I know this doesn't help the iOS people, sorry.

On the other hand, a C or C++ client library could be used on Android via NDK (native code support), but I'd prefer to port the existing source for:

a) robustness, alternate implementation
b) to learn how it works
c) clean it up and help add new features

The existing C++ code is terrible for learning and understanding what's happening. Hopefully once I'm done with the Java port it could be ported back to C++ or even over to Obj-C without too much difficulty.

I would be interested in developing such a library. I have my pet-project https://github.com/blueCommand/libbitcoin which was supposed to be something like that but as can be seen, it is not that far gone :-)

If we can gather a couple of people to write such a library with a common goal for a lightweight libbitcoin that would be awesome.

Your idea to use Haskell or ocaml for a reference implementation is probably a good idea. 

But I would still like to see a c library very much indeed. So much could be done with a simple c library.

Sorry, I meant a language to write operating systems.

I'm talking about a reference implementation, so I think there's no conflict between us.

I thought the purpose was to use it for the unix operating system and find a better way to program operating systems in general.


That was an example. If bitcoin would ever become a properly used currency it needs to be more than a thing you use on your desktop computer.

It's hard to even make clients for mobile devices at the moment. That's what led me here, I wanted to make an iOS client for bitcoin but I can't when it's like how it is today.

What I don't see is the micrcontroller thing.

Safe code is easier to write in some languages than others. C's original purpose was to write programming languages. I agree that multiple implementations is good but I'm talking about the "official" one, the "reference" implementation against which others must be tested, the executable documentation.

More so than C? And there's no reason why you can't make safe code in C. You could (and perhaps should) have multiple implementations of bit coin. I suggest having a C implementation would be beneficial, especially more so than C++.

Why would you want to embed the library? So you can easily spread bitcoin over many devices and encourage innovation in the use of bitcoin.