bitcoinj 0.8

Summary:

Bitcoinj 0.8, a Java library for writing Bitcoin applications, has been released with support for both simplified and full verification. This release includes an SPV (Simplified Payment Verification) implementation that is competitive performance-wise with more centralized solutions that rely on custom servers. Wallets based on bitcoinj 0.8 complete first time setup for new users in only a few seconds. The vast bulk of the changes in this release are bug fixes, optimizations, and minor API improvements, including support for encryption of private keys in the wallet using an AES key derived using scrypt, a new SPVBlockStore provides dramatically better performance, and a tool to create lists of block header checkpoints that can then be used to initialize a new block store. 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, and all event listeners except transaction confidence listeners now run unlocked and core objects have been converted to use cycle detecting locks. DNS seeds are now supported for testnet, and PeerEventListener now lets you catch and process exceptions thrown during peer message processing.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. BoundedOverheadBlockStore is replaced by SPVBlockStore. The Derby based block store has been deleted, and 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.There are some known issues with the release. 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. 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.

Updated on: 2023-06-06T14:50:18.009366+00:00