After many months of work, the bitcoinj team has released version 0.13!

The highlights of this release include

* Dramatically improved performance, especially for big wallets that contain many large sendmany transactions e.g. from mining pool payouts* Much faster Tor performance* A new MySQL based block store* Ability for the wallet to use a UTXO database instead of its own internal data structures. A good place to get a UTXO database is by building one using the MySQL/Postgres/H2 block stores that come with bitcoinj. This is a major step forward for allowing bitcoinj to be easily used for making web wallets and other hosted wallet services.

Many other API cleanups, tweaks and new features have been added too. The Lighthouse crowdfunding wallet was developed alongside 0.13 in parallel and many improvements made as part of developing this smart contracts app were made available for general use in this release. So it should be easier than ever to build advanced smart contract apps now.

It covers how to use the bitcoinj wallet-template app to build a cross platform, Tor supporting, decentralised, peer to peer, 3D accelerated, block chain based document timestamping app ...... from scratch. Is that enough buzzwords for you? Then check it out!

We have released version 0.12 of bitcoinj! This release represents 8 months of work and is packed with great new features that should start showing up in your apps soon.

The most interesting new features are HD wallets, support for multisig wallets, the bundled Tor client, a better bundled GUI wallet app (this is used as the basis for a few different end user apps now, like Lighthouse) and new tutorials showing how to use the library from Javascript / how to make a custom GUI wallet app.

bitcoinj has been on a tear lately. It's gathered a big community of users and contributors. Thanks to everyone who helps make it happen!

- Kosta Korenkov (@troggy on github) has implemented the first part of married wallets support. You can now marry a wallet to a third party HD tree e.g. on a remote server and that wallet will start vending multi-sig P2SH addresses. Currently if you do this, you'll have to sign transactions yourself (this is quite easy). Hopefully in future bitcoinj will have a plugin system so different risk analysis providers can be presented with a uniform interface.

- WalletTemplate now shows how to implement online restore from seed words, with real-time validation as you type.

- Old random wallets are upgraded to HD wallets on the fly, using the oldest private key in the old wallet as the seed. This means the upgrade to HD should be seamless for our existing user base.

- Andreas implemented decryption of BIP38 encrypted private keys, as part of work he's doing on supporting paper wallets in Bitcoin Wallet for Android.

4 plus ones

4

4 comments

4

3 shares

3

Mike Hearn: If I can convince someone that I'm a trusted developer and they should send me parts of their wallet, I can as well convince them to send me their entire wallet (perhaps without realising). This isn't an attack that seems important to me.

The way the wallet industry is going, people who understand public key crypto and try to individually manage keys are on their own and always will be. MultiBit took out the ability to import private keys because it's too easy to screw up.

Anyway, the purpose of this feature is to avoid the user having to make a new backup across the HDW transition. Users hate making manual backups and suck at it (this is a big part of why they like cloud things), so not invalidating old backups is a big usability win.

Jan Møller: We were considering the same solution for Mycelium for the same reason, but chose not to because of this very problem.

If the user thinks that a private key no longer has any value he might get careless with it. "What is the problem, there is no money in it after all?"

Bitcoinj is used for many purposes, not just MultiBit.Anyway, I just wanted to give you a heads-up on our thoughts.

Mike Hearn: Yeah, sure, I appreciate the feedback. There's a key rotation feature that can be used for people who want to move all money away from private keys before a certain date, and it does generate a new HD tree for the wallet when it's activated (bitcoinj wallets can have multiple HD trees in them). So I think for the type of users who care about individual keys in their wallet, they could use an app that exposes this notion of key rotation times to them and then it should all work.

+Andreas Schildbach has been on fire lately: his commits are just rolling right in to bitcoinj master. Andreas has been improving protocol compliance, cleaning up the code and fixing long-standing warts and gaps in our API. His work not only benefits his own Bitcoin Wallet for Android app but everyone else's apps too. You can tip him at 18CK5k1gajRKKSC7yVSTXT9LUzbheh1XY4

In other news, we merged HD wallets support to master as well. Although it's a good milestone, the work isn't over yet: managing HD wallets when you have weak devices (phones) talking to weak servers (p2p nodes) is a difficult and fiddly piece of engineering. But we're making good progress and I'm hoping for a release later in the summer.

We have released bitcoinj 0.11.1. This is a bugfix release that resolves some minor issues with payment protocol verification, a Bloom filtering regression, and blocks dust transactions from entering the wallet. Combined with a new cleanup method, this should resolve the annoying 1Enjoy 1Sochi spam that has been appearing in peoples wallets lately.

We released bitcoinj 0.11! It's an awesome release with more different contributors than any previous version. Wallets with the new features it enables should start to enter beta soon.

Some of my favourite highlights: payment protocol support, P2SH address support, the new PostgreSQL block store, a new GUI wallet template app that lets you quickly bring up a custom app that has wallet functionality for experimentation or contracts apps, a much improved micropayment channel sublibrary, and a new network stack that we'll start to exploit more thoroughly in the next release.