I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most 
popular Bitcoin libraries. It is used by at least four Android wallets, three 
desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp, Lighthouse, 
BlueMatt’s relay network, bitpos, countless alt coin wallets, for academic 
research projects and much more.

This release represents 8 months of work. The biggest new feature is HD 
wallets. Other notable enhancements include a bundled Tor client that can be 
activated with one line of code, support for multisig wallets, much faster and 
deterministic ECDSA, many API improvements and big upgrades to the included GUI 
wallet which can be seen in a new screencasted tutorial.

The commit hash of bitcoinj 0.12 is 83a9a71f3fff3f223d0737ad758b519a39dbbd62. 

New in this release

Privacy enhancements:
Wallets are now hierarchical and deterministic (HD) by default, using the BIP32 
specification. Support for mnemonic codes (BIP 39) is also included. Change and 
receive addresses are no longer being reused. Old wallets are upgraded in place 
using the private key of the oldest non-rotating key as the seed bytes, so old 
backups remain valid.
Thanks to devrandom, we have an integrated Tor mode using the Orchid library. 
The user does not have to install the Tor client as it’s all pure Java. 
WalletAppKit users can enable usage of Tor with a single line of code. This 
support should be considered experimental for now.
Thanks to Kosta Korenkov, we have an experimental multisig wallets 
implementation. Multisig (also “married”) wallets are HD wallets that are 
connected to a third party risk analysis service or device. When married, the 
wallet tracks multiple BIP32 key trees, keeps them in sync and starts vending 
P2SH addresses.
As part of this work, transaction signing is now pluggable. TransactionSigner 
implementations can be added to the wallet and will be serialized into and out 
of the users saved wallet file. Signers are given a transaction to sign in 
sequence. This is intended for risk analysis providers to provide a class that 
talks to their server to get a signature of the right form, so that all 
bitcoinj based wallets can be easily upgraded to support the new provider.
Reject messages are now deserialized and logged, though not yet exposed in the 
Upgraded to Guava 16 and Bouncy Castle 1.51. Thanks to Peter Dettman and the 
rest of the Bouncy Castle team, bitcoinj now uses deterministic ECDSA for 
signing and we’re now using an accelerated secp256k1 implementation that 
exploits the special properties of this curve, for dramatically faster 
Payment protocol code improvements: Some X.509 utility code was refactored out 
of PaymentSession for general usage. StartCom was added to the default trust 
store which was promoted to override the system trust store on non-Android 
platforms. A command line tool to dump requests to stdout was added.
Thanks to Andreas Schildbach:
We are now BIP62 (canonical push encodings) compliant.
A new Coin class replaces usage of BigInteger for marking values that are 
quantities of bitcoin. Formatting has moved into the new MonetaryFormat class.
The wallet now saves the fee paid on transactions we calculated ourselves. This 
is useful for putting it into a wallet user interface.
Transactions can have user memos and exchange rates attached, that will be 
saved by the wallet.
Support for decrypting BIP 38 protected private keys has been added.
Checkpoints can now be stored textually as well as in the old binary format.
There is also a new BtcFormat API that provides an alternative to 
MonetaryFormat that plugs in to the java.text framework.
Added new DNS seed from Addy Yeow.
Wallets can now have string->byte[] mappings attached to them, for lighter 
weight extensions.
Thanks to Richard Green, there is now a Python version of the ForwardingService 
program from the getting started tutorial. This shows how to use bitcoinj from 
Python using the Jython interpreter.
bitcoinj now probes localhost for a Bitcoin node and automatically uses that 
instead of the P2P network, when present. This means any bitcoinj based app can 
be easily upgraded from SPV to full security just by running Core at the same 
time: no setup needed.
Thanks to Michael Bumann, there are now more example apps showing how to use 
parts of the API.
WalletTemplate/WalletAppKit improvements. WalletTemplate is a demo app that 
shows how to create a cross-platform GUI wallet with a modern style and 60fps 
animations. WalletAppKit is a very high level API for creating apps that have a 
Bitcoin wallet:
Now supports mnemonic code and restore from seed words. A date picker is 
provided to cut down on the amount of chain that needs to be rescanned.
Support for encrypting wallets. Password is requested when needed. The 
difficulty of the scrypt function is selected to always take a fixed number of 
seconds even if hardware gets more powerful.
Some new animation and utility code backported from Lighthouse.
Tor support
Thanks to Martin Zachrison, the micropayment channels implementation has 
received various improvements.
Thanks to Eric Tierney (Circle), the Postgres store can now take a custom 
The Bloom filtering API has been extended so FilteredBlock objects can now be 
produced from Block objects given a BloomFilter. Previously there was support 
for client-side Bloom usage but no implementation of the generation part.
Many other bugfixes, cleanups, minor tweaks and small new APIs.
Documentation and tutorials

A JavaScript tutorial has been added, showing how to use bitcoinj from this 
language. More tutorials in other languages will come in future.
The “Working with the wallet” document has been significantly extended to cover 
encryption, watching wallets, HD wallets and multisig/married wallets.
A new document and accompanying screencast shows how to extend the 
WalletTemplate app to have a transactions list, and then make a native/bundled 
packages that don’t need the user to install Java. By following this tutorial 
you will learn how to make a basic cross platform desktop wallet of your own.
All other docs were refreshed to the latest APIs.
API changes

The package name has changed to org.bitcoinj and the core Maven artifact name 
is now “bitcoinj-core”. You can auto-port most of your code by running find . 
-name '*.java' \| xargs sed -i .bak 's/com.google.bitcoin./import 
Wallet.completeTx now throws more precise unchecked exceptions in edge cases, 
instead of IllegalArgumentException.
The use of BigInteger to represent quantities of Bitcoin has been replaced with 
the more efficient, type safe and useful class Coin. Coin is mostly source 
compatible with BigInteger so you can probably just do a search and replace to 
update your codebase. Utils.bitcoinValueToFriendlyString and friends moved to 
NetworkParameters.getProofOfWorkLimit was renamed to getMaxTarget for 
consistency with other Bitcoin codebases.
The library no longer uses the misleading term “nanocoins” to mean satoshis 
(the old term predated the use of the word satoshi to describe the smallest 
possible amount of bitcoin).
TransactionConfidence no longer tracks total work done.
Because outputs are now shuffled any code during that assumes the ordering is 
preserved will break. You can set the shuffleOutputs field of SendRequest to 
false to disable this behaviour if you need to.
The ECKey and HD API’s have changed quite a bit: several constructors were 
replaced with clearer static factory methods that make it more obvious how 
their parameters are interpreted. The new methods don’t change their behaviour 
depending on the pattern of nulls passed into them.
Some unit testing utilities have been moved to the new testing subpackage and 
cleaned up/rearranged. It should be easier to write unit tests for your app 
that need a simulated network now. DeterministicKey now derives from ECKey.
We now use Utils.HEX.encode() and Utils.HEX.decode() to do translation to and 
from base 16.
Transaction.hashTransactionForSignature was renamed to just hashForSignature.
The subVer string sent by bitcoinj now has a lower cased first component.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
Bitcoin-development mailing list

Reply via email to