[Bitcoin-development] bitcoinj 0.8

[Bitcoin-development] bitcoinj 0.8

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] bitcoinj 0.8

[Andy Parkins]

On Tuesday 09 April 2013 22:03:35 Mike Hearn wrote:

> 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

Not quite secure yet, because you didn't sign your email.


Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

Re: [Bitcoin-development] bitcoinj 0.8

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

The key in the message was used in my last announcement, so that
establishes continuity there.

But regardless, all mails I send are signed automatically by Gmail using
either the gmail.com consumer key (for my posts to this list) or the
google.com corporate key (for my posts to the bitcoinj lists), see
dkim.orgfor more details on this. Whilst this is not signing in the
GPG web of
trust sense, realistically the Gmail DKIM keys are much safer than any key
I could create/maintain, and my ability to sign mail as hearn@google.com is
controlled by hardware second factors and various other rather intense
security systems I can't discuss.

I've considered just not having the additional Bitcoin-key based signatures
at all, but it would help keep continuity in the case that I leave Google
or if there's a DKIM key rotation.



On Wed, Apr 10, 2013 at 10:58 AM, Andy Parkins <andyparkins@gmail.com>wrote:

> On Tuesday 09 April 2013 22:03:35 Mike Hearn wrote:
>
> > 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
>
> Not quite secure yet, because you didn't sign your email.
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins@gmail.com
>

[-- Attachment #2: Type: text/html, Size: 2066 bytes --]