Hello,
I'm pleased to announce version 0.10 of bitcoinj, a Java library for
writing Bitcoin applications. BitcoinJ has been used to create everything
from end-user wallet apps to network crawlers to SatoshiDice.
To learn how to obtain bitcoinj 0.10, please see the following page:
https://code.google.com/p/bitcoinj/wiki/UsingMaven
The v0.10 release is signed by Andreas Schildbach's GPG key. The git hash
of the release is 777e6781d789. This paragraph is signed by the same
Bitcoin key as with previous releases (check their release announcements to
establish continuity).
Signature:
H9Nl7FPnmrUOmjhUZ0+xB4YW3q5F5gIkGdvllsDWmWYvOkNQHAE9jZE0I/qE1VfLPeMV+Rzo7geTB43uDSFSMek=
*New in this release*
- An implementation of *micropayment channels* was added. There have
been many bugfixes and improvements since the first announcement. This
feature allows you to set up a 1:1 payment relationship with a remote
server and after a short setup process send very tiny payments, very
rapidly. It's suitable for metered billing applications. An article,
Working with micropayments explains how to use it. This work was a joint
effort between Matt and myself.
- A simple sublibrary has been added that provides async IO based
client/server classes that transmit length prefixed protocol buffers.
- Thanks to Matija Mazi, some classes have been added that implement *the
BIP 32 deterministic wallet algorithm*. Note that these classes are not
yet used elsewhere in the system and full deterministic wallet support is
therefore not available, however, a low level API is available for
experimentation. That API is very likely to change in future releases so
don't get too attached to it.
- Thanks to Gary Rowe, we have integrated *a new Maven plugin* that
checks the SHA1 hashes of downloaded dependencies against a hard-coded
list. This means that even if an upstream Maven repository or developer
were to be compromised, library dependencies could not be switched out for
corrupted versions without someone noticing. For 0.10 the dependency hashes
were just initialised based on what was already downloaded. In future,
reproducible builds of upstream dependencies and auditing of changes would
provide better security. You can and should use Gary's
pluginhttps://github.com/gary-rowe/BitcoinjEnforcerRules in
your own projects to defend against a possible compromise of the bitcoinj
repository.
- *Callback handling* has been much improved. Each event listener can
have an Executor specified which takes responsibility for running the
callback. If you don't specify one they run by default on a single
background thread, the user thread, instead of the origin framework
threads. This means your callbacks no longer need to be thread safe as
they're always run serially. You can also change the default executor if
you would like to control the thread on which callbacks run, for example to
marshal them into your GUI toolkit thread automatically. This fixes some of
the most painful parts of the pre-0.10 API, for instance that transaction
confidence listeners were not allowed to re-enter the library.
- *Exception handling* has also improved. You can assign a global
Thread.UncaughtExceptionHandler which receives any exceptions thrown on
the user thread (i.e. by your own event listeners), as well as any internal
exceptions thrown by network threads (like inability to parse a message
sent by a remote peer). Because your listeners now run on a separate thread
by default, you can no longer accidentally cause internal data corruption
or prevent other callbacks from running by leaking exceptions out of your
callbacks; a subtle knife-edge in the previous API.
- Support for *automatic wallet key rotation* has been added.
- We now require Bloom-capable (0.8+) peers by default and will
disconnect from older nodes. This avoids accidental bandwidth saturation on
mobile devices.
- The wallet now accepts timelocked transactions if it created them
itself.
- The wallet can be told to empty itself out, in which case the fee will
be subtracted from the total amount instead of added. This simplifies the
common case of wanting to send your entire balance whilst still including a
fee.
- Some JNI peers for event listeners were added. Auto-generated JNI
bindings are experimental and not yet merged in to the mainline codebase:
for now they are available as part of a separate project on github. This
work allows you to access the bitcoinj API using relatively natural looking
C++ code and an embedded JVM.
- You can now register custom PeerFilterProvider implementors to add
things to Bloom filters that aren't necessarily in wallets.
- We have begun adding nullity annotations to the API. Combined with a
strong static analysis engine like FindBugs or the IntelliJ Inspector, you
can find cases where you
