1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
|
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'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'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,'DejaVu Sans Mono','Bitstream Vera Sans Mono=
','Lucida Console',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't confirmed yet even if your wallet wasn'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,'DejaVu Sans Mono','Bitstream Vera=
Sans Mono','Lucida Console',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'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'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,'DejaVu Sans Mono','Bitstream Vera Sans Mono','=
Lucida Console',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,'DejaVu Sans Mono','Bitstream Vera Sans Mono','=
Lucida Console',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,'DejaVu Sans Mono','Bitstream Vera Sans =
Mono','Lucida Console',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't used much.<=
/li><li style=3D"margin-left:15px;margin-bottom:0.3em">The static=C2=A0<tt =
style=3D"font-family:Monaco,'DejaVu Sans Mono','Bitstream Vera =
Sans Mono','Lucida Console',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,'DejaVu Sans Mono','Bitstream Vera Sans Mono','=
Lucida Console',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'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'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'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--
|