path: root/54/66b20fb4428091913995e001d31fb139524da5

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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CANEZrP1Y0JwQU-xSY1KdKrLnGDA4PhDwo9LtGkMaoCGw9=sZKA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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<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

--e89a8fb1f9c4fdac2704d9f3e270
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif;font-size:13px=
">I&#39;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.</span><div style=3D"font-family:ari=
al,sans-serif;font-size:13px">
<br></div><div style=3D"font-family:arial,sans-serif;font-size:13px"><div s=
tyle=3D"margin:0px;padding:0px;border:0px;vertical-align:baseline"><font fa=
ce=3D"Arial, Helvetica, sans-serif"><span style=3D"font-size:12.72727203369=
1406px">To get bitcoinj 0.8, check out our source from git and then run=C2=
=A0</span></font><b style=3D"font-family:Arial,Helvetica,sans-serif;font-si=
ze:12.727272033691406px">git fetch --all; git checkout=C2=A0</b><font face=
=3D"Arial, Helvetica, sans-serif"><b>cbbb1a2bf4d1</b></font><span style=3D"=
font-family:Arial,Helvetica,sans-serif;font-size:12.727272033691406px">. 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=A0</span><span st=
yle=3D"font-family:Arial,Helvetica,sans-serif;font-size:12.727272033691406p=
x">16vSNFP5Acsa6RBbjEA7QYCCRDRGXR</span><span style=3D"font-family:Arial,He=
lvetica,sans-serif;font-size:12.727272033691406px">FH4m.</span></div>
<div><br></div><div>Signature for previous paragraph:=C2=A0H8itldUGHHt8jXmF=
wRX/gASXrhG1a/k0VG0vwFMjQCAWDpxgA17ODfSPFNgAOPDnPmT1gLLUlHsEqwXHBoj+JMU=3D<=
/div><div><br></div><div style>You can also verify the <a href=3D"http://go=
ogle.com">google.com</a> DKIM signature on the <a href=3D"https://groups.go=
ogle.com/forum/?fromgroups=3D#!topic/bitcoinj-announce/IB7dlc_g9sU">officia=
l announcement</a>.</div>
<div><br></div><div style>I&#39;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.</div>
<div style><br></div><div><br></div><div><b>New in this release</b></div><d=
iv><ul style=3D"padding-left:25px;max-width:62em;font-size:12.8000001907348=
63px"><li style=3D"margin-left:15px;margin-bottom:0.3em">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.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em">A new=C2=A0<tt style=3D"=
font-family:Monaco,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono=
&#39;,&#39;Lucida Console&#39;,monospace;font-size:12px;max-width:66em">SPV=
BlockStore</tt>=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.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em">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=
.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em">Bloom-filtering capable =
nodes are now queried for transactions at startup, meaning you can receive =
payments that weren&#39;t confirmed yet even if your wallet wasn&#39;t runn=
ing at the time.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em">Many static analysis war=
nings have been cleared.</li><li style=3D"margin-left:15px;margin-bottom:0.=
3em">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.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em">DNS seeds are now suppor=
ted for testnet.</li><li style=3D"margin-left:15px;margin-bottom:0.3em"><tt=
 style=3D"font-family:Monaco,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera=
 Sans Mono&#39;,&#39;Lucida Console&#39;,monospace;font-size:12px;max-width=
:66em">PeerEventListener</tt>=C2=A0now lets you catch and process exception=
s thrown during peer message processing. This is useful for reporting crash=
es that don&#39;t take out your entire app, but just result in disconnectio=
n of a peer.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em">Matt Corallo&#39;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.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em">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.</li>
</ul><p style=3D"line-height:1.25em;max-width:64em;font-size:12.80000019073=
4863px"><b>API changes:</b></p><ul style=3D"padding-left:25px;max-width:62e=
m;font-size:12.800000190734863px"><li style=3D"margin-left:15px;margin-bott=
om:0.3em">
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.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em"><tt style=3D"font-family=
:Monaco,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;=
Lucida Console&#39;,monospace;font-size:12px;max-width:66em">IrcDiscovery</=
tt>=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.</l=
i>
<li style=3D"margin-left:15px;margin-bottom:0.3em"><tt style=3D"font-family=
:Monaco,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;=
Lucida Console&#39;,monospace;font-size:12px;max-width:66em">BoundedOverhea=
dBlockStore</tt>=C2=A0is now deprecated. It was replaced by=C2=A0<tt style=
=3D"font-family:Monaco,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans =
Mono&#39;,&#39;Lucida Console&#39;,monospace;font-size:12px;max-width:66em"=
>SPVBlockStore</tt>. The file format has changed, so BOBS will stick around=
 for a while so users can be upgraded.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em">The Derby based block st=
ore has been deleted. It only supported SPV mode and wasn&#39;t used much.<=
/li><li style=3D"margin-left:15px;margin-bottom:0.3em">The static=C2=A0<tt =
style=3D"font-family:Monaco,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera =
Sans Mono&#39;,&#39;Lucida Console&#39;,monospace;font-size:12px;max-width:=
66em">NetworkParameters</tt>=C2=A0methods now vend singleton objects.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em"><tt style=3D"font-family=
:Monaco,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;=
Lucida Console&#39;,monospace;font-size:12px;max-width:66em">WalletEventLis=
tener.onCoinsSent</tt>=C2=A0is no longer run when a transaction sends to se=
lf but the balance doesn&#39;t change.</li>
</ul><p style=3D"line-height:1.25em;max-width:64em;font-size:12.80000019073=
4863px"></p><p style=3D"line-height:1.25em;max-width:64em;font-size:12.8000=
00190734863px"><b>Known issues:</b></p><ul style=3D"padding-left:25px;max-w=
idth:62em;font-size:12.800000190734863px">
<li style=3D"margin-left:15px;margin-bottom:0.3em">Transaction confidence l=
isteners are still run with the wallet lock held, which means it&#39;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.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em">If multiple peers discon=
nect simultaneously it&#39;s possible for the system to deadlock due to Net=
ty allowing uncontrolled reentrancy when sending outbound messages (<a titl=
e=3D"Unexpected re-entrancy via Channels.write() leads to Netty/user lock i=
nversion" href=3D"https://code.google.com/p/bitcoinj/issues/detail?id=3D381=
" target=3D"_blank" style=3D"color:rgb(0,0,204)">issue 381</a>).</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em">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.</li>
<li style=3D"margin-left:15px;margin-bottom:0.3em">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.</li>
</ul><div><font face=3D"arial, sans-serif">There is a further list of limit=
ations and issues available on the wiki here:</font></div></div></div><div =
style=3D"font-family:arial,sans-serif;font-size:13px"><font face=3D"arial, =
sans-serif"><br>
</font></div><div style=3D"font-family:arial,sans-serif;font-size:13px"><fo=
nt face=3D"arial, sans-serif"><a href=3D"https://code.google.com/p/bitcoinj=
/wiki/Limitations" target=3D"_blank">https://code.google.com/p/bitcoinj/wik=
i/Limitations</a></font></div>
</div>

--e89a8fb1f9c4fdac2704d9f3e270--