Under the images I can put "Pictures created by Alan Reiner, developer of Bitcoin Armory (http://bitcoinarmory.com/)"?

I'm hoping following bitcoinj will also help (It's very easy to read), the issue is that bitcoinj doesn't implement everything so I'll have to look into other code that does implement things like the script properly. The C++ client has the code but it harder to read. Documentation no doubt helps me understand what I'm doing rather than do a piece by piece port, so I can make better code.

This library aims to have zero dependencies except the standard C library making it small and easily portable. This doesn't mean I will reinvent the wheel in every single case. There are many open source implementations of the things my library will need. I can adapt these tried and tested algorithms to suit the specific needs of this library. In some cases it may be more or less copy and paste and in other cases it may require tweaks or substantial modifications.

At the moment I'm implementing specialist functions that include operations between a bignum and an 8 bit integer. This is for the base-58 encoder/decoder. If anyone knows a better solution to the base-58 stuff, please tell me or feel free to work on it yourself. When I'll be going operations between two bignums it should be simple to derive my code from bignum libraries and then I can derive the cryptography code from open-source libraries such as OpenSSL too.


Well wouldn't that be interesting. You would need an implementation of standard library features including dynamic memory allocation but I plan absolutely no additional dependencies other than the standard C library. Of-course, feel free to contribute anything, including ideas.


Thanks. I am doing this largely to learn as well as to create something functional. The images you have made a pretty nice. Would I be able to use them in my documentation? I do hope to build a nice documentation for my library.

For the next few days I'll be busy with other things but I'll when I'm back to this library I hope to sort of the base-58 code and also modify the OOP so that the virtual function tables are initialised at compile time which makes more sense.


The library should be compilable with C compilers providing C99 with the standard library is supported (At least everything the library uses). Perhaps the library will need minor tweaks for compilers that aren't compatible with some features in C99 but that's not going to cause many headaches I sure. The biggest headache would be to implement the standard library features for microcontrollers with no out of the box standard C library support.

But are you saying some 8-bit architectures come with compilers that only allow 8 bit types? That would be pretty rubbish. The compilers should support up-to 64 bit integer types (int64_t). I believe long long types should be at least 64 bits so a compiler that keeps to the C specification properly should support it.

If anyone understands microcontrollers well and can advise on how the library can be designed with microcontroller portability in mind, please share your knowledge.

@miscreanity: I guess my idea of piano certificate money wont kick off then? I was going to call them keys and 88 keys would equal a piano with 88 keys redeemable for one piano.

The number one reason is that I've never liked C++. I get on with C much better.

C++ programmers can pretty much read and use C code with little problem. C++ code is not so easy for solely C programmers. Not only can the library be used by C programmers, it can be written by C programmers that don't get on with C++.

And implementing OOP features in C is not as hard as it sounds once you know how.

But yes, that's a common question.

Hello.

I am currently making a bitcoin library named cbitcion. This is a very incomplete library in the early stages of development. The point of the library is to bring powerful bitcoin features directly to the C programming language, with a focus on documentation, portability and powerful features. Hopefully, considering this is C, it should have good performance as well. Perhaps the library could be used or modified for use in embedded device applications.

The library will be low level. It is not intended to be a client library for easy bitcoin functionality. Instead it should give programmers the tools to make bitcoin applications from basic abstraction on the bitcoin protocol. The design of cbitcoin should hopefully allow programmers to make a diverse range of bitcoin applications.

Feedback and contributions are welcome. This is the code: https://github.com/MatthewLM/cbitcoin/

I've given up developing iPhone apps to put a lot of my time towards this, so hopefully it will come along reasonably quickly.

There will be inevitable costs to this project. If anyone would like to help this project financially, donations are very welcome: 1D5A1q5d192j5gYuWiP3CSE5fcaaZxe6E9

Do not hesitate to contact me regarding this project via the email address cbitcoin@thelibertyportal.com

Thanks!

Matthew M

To think Nautilus will do well, you have to assume they can actually mine at the concentrations in their resource estimate report and that the costs can remain under control. So it all sounds interesting but things usually turn out worse than planned.

What do people think to this company? No ordinary mining company, they aim to use undersea mining for metals: http://www.nautilusminerals.com/s/Home.asp

Has this been posted? What do people think? http://www.youtube.com/watch?v=tj2s6vzErqY

This is a pretty nice chart:

There seems to be a few simple Reed Solomon algorithms available online so I don't think it would be a major problem implementing, assuming these algorithms work.

Your format seems pretty good. Where would I be able to find out more about the error-correcting checksums. You say they can fix up to one byte. Sounds good enough to me but what do I know? Would people say that's the only error correction needed?

What do people think about other wallet formats?

Thanks retep. I was thinking the same thing: Instead of a random delay, you could profile the algorithms to estimate the longest time and add a delay up until this time each time the algorithms are run. An additional random delay would be good also. As for the power problem, wouldn't it be best to focus on the hardware to mask this? With the algorithms there may be detectable power variations for the actual different operations computed right?

I'm looking through the code. I guess the ECDSA and bignum algorithms were implemented more or less from scratch? I might use some of you algorithms for the C library I'm making. I was looking at other libraries including OpenSSL which is what the C++ client uses but none easily allow me to include only the specific parts I need into my library.

I found this:


Does this matter for the purposes of this device? And what about using bitcoin on a PC?

For a time-based attack an attacker would need to determine the start and end times of an operation. For signing transactions on a PC I don't see how time information could leak out to an attacker. From what I can tell the attacker would need some sort of access to the computer itself, in which case wallets are vulnerable anyway. So would the algorithms need to be secured against this type of attack when using bitcoin?

Perhaps using a random sleep period when signing transactions would protect against the attack and may allow for better optimisation. I found this but it isn't too keen on the random time delays: http://www.cryptography.com/public/pdf/TimingAttacks.pdf The blind signature technique wouldn't be applicable (unless I don't know something). Does anyone have any thoughts on this?

It's interesting. From a quick look it seems to port bitcoinj in a very direct way. My library may be radically different in areas.

You mention profile guided optimisation. GCC can do that can it not? Is the Java PGO somehow better? I will look into optimisation more when I get to that point.

But I look forward to seeing your native library for C++ come to life. Will be interesting.

Well, once my library is done I can compare the two. Java has other problems which include the greater memory usage and slower load times. The natively compiled bitcoinj would be better performance wise. I've read that natively compiled Java can be almsot as fast as C. I don't know much about compiling Java into native code though.

With a C library it gives other people more choice. I see no reason why there cannot be several different libraries to satisfy different people. This project is good for me since it's part of a much larger project and making my own implementation will help me learn how to implement what is needed for the larger project (What this project is, is secret, sorry). My library will also have quite fundamental differences to bitcoinj. Already in the code there are some differences; for instance ChildMessage is made completely redundant in my library.

Maybe I'm wasting my time and I should just work on top of bitcoinj but I doubt it, especially since to learn the bitcoin protocol it's probably a good idea to program an implementation of it.

But I wish the greatest luck with bitcoinj.

Thanks for the reply Mike.


Yes, in C for performance largely.


Since I'm re-implementing the library in C I obviously cannot do that but I might take some time out to submit to bitcoinj simple improvements. I'll make sure to make a NOTICE file before putting up the code. I should hopefully be ready to put something up with a month, though it may take several months to implement the entire requirements. I'll be hosting it here: https://github.com/MatthewLM/cbitcoin

This is very nice and makes much more sense to me than the C++ client code. I'm making my own library (Which will use GPLv3) based on this. I'm not modifying the source files but rather basing my own implementation from this library. It seems I can just mention bitcoinj in a NOTICE file, right?

I saw in the Message class when bitcoinSerialize is called without caching enabled (parseRetain) or when the message is not the entire byte array it will copy an array without any need to, since it is either already copied from the byte array or taken from the bitcoin serialisation directly.

So my library will handle all that differently and only copy when necessary. Maybe I missed something since I've not looked through every single part yet.

The battery life of mobile phones if a good point. It will depend on the reliability of the card and the price. Time will tell.

Using bitcoin with a smartphone wouldn't cost any extra with internet usage included in your contract unless you were charged for extra usage and went over the usage limits. There is also wifi.

Could you implement some anonymity for smart-phones? Some way to hide the IP address if you every really had to for whatever reason. Is this something people really want?


A lot of people already use smart-phones, especially people tech-savvy enough to be using bitcoin (I would guess the majority of bitcoin users would have smart-phones but I could be wrong). This would only be beneficial for those that do not have smart-phones and don't want them.


Well if smart-phones are in risk of malware that could manipulate any bitcoin software. Do smartphones have many vulnerabilities? I seem to remember one smartphone had a vulnerability hackers were taking advantage off which was fixed. I forgot about that now so if anyone is more aware please tell me.