From: Mike Hearn <mike@plan99•net>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] bitcoinj 0.8
Date: Tue, 9 Apr 2013 23:03:35 +0200 [thread overview]
Message-ID: <CANEZrP1Y0JwQU-xSY1KdKrLnGDA4PhDwo9LtGkMaoCGw9=sZKA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5715 bytes --]
I'm happy to announce the release of bitcoinj 0.8, a Java library for
writing Bitcoin applications. Both simplified and full verification are
supported. BitcoinJ has been used to create everything from end-user wallet
apps to network crawlers to SatoshiDice.
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<https://groups.google.com/forum/?fromgroups=#!topic/bitcoinj-announce/IB7dlc_g9sU>
.
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<https://code.google.com/p/bitcoinj/issues/detail?id=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
[-- Attachment #2: Type: text/html, Size: 9739 bytes --]
next reply other threads:[~2013-04-09 21:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 21:03 Mike Hearn [this message]
2013-04-10 8:58 ` Andy Parkins
2013-04-10 10:02 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP1Y0JwQU-xSY1KdKrLnGDA4PhDwo9LtGkMaoCGw9=sZKA@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox