Topic: [ANNOUNCE] BitCoinJ 0.4 (Read 2994 times)

+1
It's under NDA, but we (the company I work for) have something coming too. Don't get your hopes up about a release any time soon, but we're using bitcoinj.

The quality of the converted code apparently is very high with the IKVM project.  We could protentaly setup an automated conversion of BitcoinJ to C#.

While helping impove the IKVM project.

But I agree... C# is just so-much nicer to program than Java.

I wish the C# version were still active.

Well, there's IKVM to convert Java bytecodes and that source code converter Xamarin used to port whole Android to C#... I guess I'll manage somehow when the time comes. But it would feel better if someone was maintaining and securing a Mono/.NET Version.

It's sad how many industry people are oblivious to the Mono/.NET intersection as a platform. Google should never have chosen Java for Android! But even now that Oracle is annoying as hell and Xamarin places an alternative right in front of them, Google doesn't seem to even think about it. Just because Microsoft originally specified it, it can't be good. Nobody gives a damn that C# is an independent standard now, while Java is Oracle and Oracle likes excessive lawsuits. And since the management goes this way, many miss out on the one closer look that shows just how far behind Java is these days.

TL;DR: Want me to develop with something? Then CLI compatibility is mandatory.

Ive been watching bitcoinj project for awhile, glad to see its proggressing. I hope utlize this library in future projects to come.

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.

Sure, if you want to learn things then go right ahead. However it's a ton of work, especially if you want to keep up. There was a port of bitcoinj to C# a while ago but the author fell behind.

It's easy to assume that if you compile to native code things must get faster, but the JVM is a very good compiler and startup time these days has been quite well optimized also. In some cases Java can beat the equivalent C or C++ program, depending on various factors like how much you benefit from profile guided optimizations and how careful you are about generating garbage. For startup time, running wallet-tool with no arguments (just prints the help text) completes in about a second on my laptop, which is probably good enough.

I uploaded my work so far on native compilation:

  http://code.google.com/r/hearn-bitcoinj/source/browse/?name=native#git%2Fnative

It's far enough along that I built and ran a simple native MacOS X Cocoa app, in Xcode, that loaded a wallet and put its debug dump into a text widget. The code is quite straightforward and interacting with bitcoinj looks like regular C++. There is no JVM dependency:

  http://code.google.com/r/hearn-bitcoinj/source/browse/native/examples/CocoaDemo/CocoaDemoAppDelegate.mm?name=native

There are some notes here:

  http://code.google.com/r/hearn-bitcoinj/source/browse/Using%20bitcoinj%20from%20native%20code.txt?name=native

Note that it's still very rough and will take quite a bit of work to get to the point I did. I haven't written any scripts or automated any of the setup work yet.

My eventual goal is to allow bitcoinj to work on iOS so we can have a lightweight/SPV client like Bitcoin Wallet, that talks directly to the p2p network. But opening up bitcoinj to the world of C++ developers is just generally useful in its own right.

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.

I think you'll find if you profile the library Java is not a performance bottleneck. Algorithms are, in particular, how we manage the block chain (unnecessary disk seeks). I'm happy to help you achieve your perf goals if you outline them.

If you'd like to access the library from (Objective) C++ rather than use Java, I have a working prototype of compiling bitcoinj to fully native code that can be called from a native app, without a JVM. It should be either in the next release or the one after.

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

Progress is pretty good. There should be a new release soon. There hasn't been much work in the past couple of weeks as we've all been busy with other things.

0.5 will be a fairly boring release, focussed on bugfixes and ensuring everyone moves to protobuf wallets.

Hey Mike, how is the progress to the next release going?

You mean you're re-implementing the library? If you don't mind me asking, what for?

I think mentioning that the library is based on bitcoinj would be good to do, if only to avoid confusion. If you do make improvements to bitcoinj, please do consider contributing them back under the original license.

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.

Mike works for Google in Switzerland and bitcoinj is his "20%" project.

yes, what does "Authored by Google" mean from a practical standpoint?

Great work Mike !

:-)

Congratulations!

Google? Official?

I'm pleased to announce the release of BitCoinJ 0.4, the leading Java implementation of the Bitcoin protocol. Authored by Google and a cast of open source contributors, BitCoinJ implements simplified payment verification, a lightweight mode in which no central server or authority is needed but the resource requirements are still low enough to be usable on smartphones.

This version of the library is used in the new releases of Android Wallet and MultiBit.

New in this release

• Ability to use "getheaders" to quickly catch up new users to the head of the chain. This is a big performance win.
• ECKeys no longer require the private part, allowing for "watching wallets" that cannot spend, but still gather and track the transactions associated with the public keys.
• A new API that implements transaction confidences. Get a quick summary or detailed information about how much confidence you can have that a given transaction won't be reversed.
• A new DerbyBlockStore that stores block headers and related data in the Apache Derby relational database.
• Protocol buffers are now a supported serialization format for the wallet. This means BitCoinJ based protobuf wallets can be read and manipulated by any language/platform with a protobufs implementation, which is most of them. There are extension points in the format to allow third parties to add new features.
• Various new event listeners that help you learn when the state of the wallet or transactions change.
• Support for post February 20th version handshakes (most library users already got this fix via backports)
• All event listeners are now allowed to remove themselves during their own execution.
• New APIs that allow you to create offline transactions and then broadcast them at a later point. Pending relevant transactions are recorded and announced to all newly connected nodes, ensuring a transaction won't "get lost" if there was flaky network connectivity at the time of creation. Pending transactions are supported much better in this release than in previous releases.
• Wallet now can now take an invalid transaction and complete it by adding sufficient inputs and a change output. This enables the creation of multi-sends, as well as making experimentation with contracts easier.
• Support for BIP 14: apps can now set their own "user agent" which will be put in the subVer field along with the library version.
• Updated DNS seeds list.
• A new WalletTool program for command line usage, and a ToyWallet app showing how to set everything up.
• Support parsing and checking of alert messages.
• New articles explaining how to use the library: Working with transactions, Working with the wallet
  
• The usual assortment of bugfixes, new APIs, robustness and test suite improvements.

Thanks to everyone who contributed to this release, in particular Andreas Schildbach, Miron Cuperman, Roman Maneleil, Chris Rico and Vasile Rotaru.

In the next release cycle, I'll be focusing on the following areas:

• Real support for transaction fee calculations (most users apply a custom patch for this today)
• A better block chain API
• Have the library manage save points for the wallet itself
• Further chain download time optimizations
• More support for moving apps onto "work done" as a confidence measurement

Of course contributors are welcome to work on whatever they want.