To get bitcoinj 0.8, check out our source from git and then run git fetch --all; git checkout cbbb1a2bf4d1. This will place you on the 0.8 release in a secure manner. This message was written on Tuesday 9th April 2013 and is signed with the following key, which will be used in all release announcements in future: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m.
Signature for previous paragraph: H8itldUGHHt8jXmFwRX/gASXrhG1a/k0VG0vwFMjQCAWDpxgA17ODfSPFNgAOPDnPmT1gLLUlHsEqwXHBoj+JMU=
You can also verify the google.com DKIM signature on the official announcement.
I'm especially happy about this release because for the first time, we have an SPV implementation that is competitive performance-wise with more centralised solutions that rely on custom servers. Wallets based on bitcoinj 0.8 complete first time setup for new users in only a few seconds, eliminating the last source of significant delays. Every operation except key import now completes more or less immediately.
New in this release
- Thanks to Jim Burton, encryption of private keys in the wallet is now supported. Keys are encrypted using an AES key derived using scrypt.
- A new SPVBlockStore provides dramatically better performance and bounded disk usage by storing block headers in an mmapped ring buffer. This makes syncing headers for new chains/wallets network limited instead of disk io limited.
- A new tool is provided to create lists of block header checkpoints that can then be used to initialize a new block store. This allows most headers to not be downloaded when initializing a new chain/wallet, making first-run of new wallets much faster.
- Bloom-filtering capable nodes are now queried for transactions at startup, meaning you can receive payments that weren't confirmed yet even if your wallet wasn't running at the time.
- Many static analysis warnings have been cleared.
- All event listeners except transaction confidence listeners now run unlocked and core objects have been converted to use cycle detecting locks. Multiple lock inversions were fixed.
- DNS seeds are now supported for testnet.
- PeerEventListener now lets you catch and process exceptions thrown during peer message processing. This is useful for reporting crashes that don't take out your entire app, but just result in disconnection of a peer.
- Matt Corallo's bitcoind comparison tool was merged in. It runs a large set of regression tests that compares the behaviour of bitcoinj in full verification mode against bitcoind.
- The vast bulk of the changes in this release are bug fixes, optimizations and minor API improvements. They are too numerous to list here, please refer to the commit logs for details.
API changes
- Event listeners were previously locked before being called, and the object being listened to was also locked. This is no longer true - your event listeners must be thread safe and the objects that triggered the event may be changing in parallel.
- IrcDiscovery is now deprecated, as LFnet has gone offline and DNS seeding can be used for both test and production networks. The code is still there in case you want to use IRC bootstrapping for a private experimental network.
- BoundedOverheadBlockStore is now deprecated. It was replaced by SPVBlockStore. The file format has changed, so BOBS will stick around for a while so users can be upgraded.
- The Derby based block store has been deleted. It only supported SPV mode and wasn't used much.
- The static NetworkParameters methods now vend singleton objects.
- WalletEventListener.onCoinsSent is no longer run when a transaction sends to self but the balance doesn't change.
Known issues
- Transaction confidence listeners are still run with the wallet lock held, which means it's possible to trigger unexpected lock inversions by doing certain things inside them. Also, confidence listeners sometimes run in places where the wallet code is not fully re-entrant, meaning that modifying the wallet whilst inside a confidence listener may cause problems. A simple fix is to run your listener code in a separate thread. A future release will fix this by ensuring that listeners only ever run at the end of wallet mutating operations and with the wallet unlocked. Core objects will also switch to using non-reentrant locks so unexpected reentrancy deadlocks early and reliably.
- If multiple peers disconnect simultaneously it's possible for the system to deadlock due to Netty allowing uncontrolled reentrancy when sending outbound messages (issue 381).
- The Wallet expects that it can store all transactions in memory (including spent transactions), eg, for rendering in lists and availability during re-orgs. On highly constrained devices like old Android phones it is possible to run out of RAM if a wallet gets very large.
- There are some bugs that can cause the wallet to get into an inconsistent state in various rare situations. The wallets can be fixed by replaying them. These bugs will be addressed as the next highest priority.
There is a further list of limitations and issues available on the wiki here:
https://code.google.com/p/bitcoinj/wiki/Limitations