Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UPfhe-0004tx-I7 for bitcoin-development@lists.sourceforge.net; Tue, 09 Apr 2013 21:03:42 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.50 as permitted sender) client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f50.google.com; Received: from mail-oa0-f50.google.com ([209.85.219.50]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UPfhc-0000re-Vc for bitcoin-development@lists.sourceforge.net; Tue, 09 Apr 2013 21:03:42 +0000 Received: by mail-oa0-f50.google.com with SMTP id n1so7936066oag.37 for ; Tue, 09 Apr 2013 14:03:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.14.226 with SMTP id s2mr19481471oec.124.1365541415394; Tue, 09 Apr 2013 14:03:35 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.167.169 with HTTP; Tue, 9 Apr 2013 14:03:35 -0700 (PDT) Date: Tue, 9 Apr 2013 23:03:35 +0200 X-Google-Sender-Auth: oSGWOFDAwHWMJJxR38nhl5wVR0c Message-ID: From: Mike Hearn To: Bitcoin Dev Content-Type: multipart/alternative; boundary=e89a8fb1f9c4fdac2704d9f3e270 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UPfhc-0000re-Vc Subject: [Bitcoin-development] bitcoinj 0.8 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 21:03:42 -0000 --e89a8fb1f9c4fdac2704d9f3e270 Content-Type: text/plain; charset=UTF-8 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 . 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 --e89a8fb1f9c4fdac2704d9f3e270 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm happy to announce the release of bitcoinj 0.8, a Java library for= writing Bitcoin applications. Both simplified and full verification are su= pported. BitcoinJ has been used to create everything from end-user wallet a= pps to network crawlers to SatoshiDice.

To get bitcoinj 0.8, check out our source from git and then run=C2= =A0git fetch --all; git checkout=C2=A0cbbb1a2bf4d1. Th= is will place you on the 0.8 release in a secure manner. This message was w= ritten on Tuesday 9th April 2013 and is signed with the following key, whic= h will be used in all release announcements in future:=C2=A016vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m.

Signature for previous paragraph:=C2=A0H8itldUGHHt8jXmF= wRX/gASXrhG1a/k0VG0vwFMjQCAWDpxgA17ODfSPFNgAOPDnPmT1gLLUlHsEqwXHBoj+JMU=3D<= /div>

You can also verify the google.com DKIM signature on the officia= l announcement.

I'm especially happy about this release becau= se for the first time, we have an SPV implementation that is competitive pe= rformance-wise with more centralised solutions that rely on custom servers.= Wallets based on bitcoinj 0.8 complete first time setup for new users in o= nly 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 Burt= on, encryption of private keys in the wallet is now supported. Keys are enc= rypted using an AES key derived using scrypt.
  • A new=C2=A0SPV= BlockStore=C2=A0provides dramatically better performance and bounded d= isk usage by storing block headers in an mmapped ring buffer. This makes sy= ncing headers for new chains/wallets network limited instead of disk io lim= ited.
  • A new tool is provided t= o create lists of block header checkpoints that can then be used to initial= ize a new block store. This allows most headers to not be downloaded when i= nitializing 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 runn= ing at the time.
  • Many static analysis war= nings have been cleared.
  • All event listeners except transaction confidence listeners now run un= locked and core objects have been converted to use cycle detecting locks. M= ultiple lock inversions were fixed.
  • DNS seeds are now suppor= ted for testnet.
  • PeerEventListener=C2=A0now lets you catch and process exception= s thrown during peer message processing. This is useful for reporting crash= es that don't take out your entire app, but just result in disconnectio= n of a peer.
  • Matt Corallo's bitco= ind comparison tool was merged in. It runs a large set of regression tests = that compares the behaviour of bitcoinj in full verification mode against b= itcoind.
  • The vast bulk of the cha= nges in this release are bug fixes, optimizations and minor API improvement= s. 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 list= eners must be thread safe and the objects that triggered the event may be c= hanging in parallel.
  • IrcDiscovery=C2=A0is now deprecated, as LFnet has gone offline and DNS seeding can b= e used for both test and production networks. The code is still there in ca= se you want to use IRC bootstrapping for a private experimental network.
  • BoundedOverhea= dBlockStore=C2=A0is now deprecated. It was replaced by=C2=A0SPVBlockStore. The file format has changed, so BOBS will stick around= for a while so users can be upgraded.
  • The Derby based block st= ore has been deleted. It only supported SPV mode and wasn't used much.<= /li>
  • The static=C2=A0NetworkParameters=C2=A0methods now vend singleton objects.
  • WalletEventLis= tener.onCoinsSent=C2=A0is no longer run when a transaction sends to se= lf but the balance doesn't change.

Known issues:

  • Transaction confidence l= isteners are still run with the wallet lock held, which means it's poss= ible to trigger unexpected lock inversions by doing certain things inside t= hem. Also, confidence listeners sometimes run in places where the wallet co= de 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 list= ener 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 w= ith the wallet unlocked. Core objects will also switch to using non-reentra= nt locks so unexpected reentrancy deadlocks early and reliably.
  • If multiple peers discon= nect simultaneously it's possible for the system to deadlock due to Net= ty 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 constrai= ned devices like old Android phones it is possible to run out of RAM if a w= allet gets very large.
  • There are some bugs that= can cause the wallet to get into an inconsistent state in various rare sit= uations. The wallets can be fixed by replaying them. These bugs will be add= ressed as the next highest priority.
There is a further list of limit= ations and issues available on the wiki here:

--e89a8fb1f9c4fdac2704d9f3e270--