diff options
author | Mike Hearn <mike@plan99.net> | 2013-08-14 14:26:27 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2013-08-14 12:26:34 +0000 |
commit | b7bf546723d88dc16a6c077f629aa4dcb1987249 (patch) | |
tree | 2879a1fe1e3e78804ecb9bcb108b54f328fbcf48 | |
parent | 898c668f09bd1b3f2f0ac32237d332131684b9f7 (diff) | |
download | pi-bitcoindev-b7bf546723d88dc16a6c077f629aa4dcb1987249.tar.gz pi-bitcoindev-b7bf546723d88dc16a6c077f629aa4dcb1987249.zip |
[Bitcoin-development] bitcoinj 0.10
-rw-r--r-- | 21/a47746089c63bf8f255637b006f693cb2ed4f7 | 343 |
1 files changed, 343 insertions, 0 deletions
diff --git a/21/a47746089c63bf8f255637b006f693cb2ed4f7 b/21/a47746089c63bf8f255637b006f693cb2ed4f7 new file mode 100644 index 000000000..da0715011 --- /dev/null +++ b/21/a47746089c63bf8f255637b006f693cb2ed4f7 @@ -0,0 +1,343 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1V9a9q-0001Ol-Fc + for bitcoin-development@lists.sourceforge.net; + Wed, 14 Aug 2013 12:26:34 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.214.175 as permitted sender) + client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com; + helo=mail-ob0-f175.google.com; +Received: from mail-ob0-f175.google.com ([209.85.214.175]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1V9a9o-0007jW-Uf + for bitcoin-development@lists.sourceforge.net; + Wed, 14 Aug 2013 12:26:34 +0000 +Received: by mail-ob0-f175.google.com with SMTP id xn12so11635829obc.6 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 14 Aug 2013 05:26:27 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.60.98.41 with SMTP id ef9mr1708211oeb.68.1376483187535; Wed, + 14 Aug 2013 05:26:27 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.76.80.165 with HTTP; Wed, 14 Aug 2013 05:26:27 -0700 (PDT) +Date: Wed, 14 Aug 2013 14:26:27 +0200 +X-Google-Sender-Auth: dji8Hn3DdGNiXtgF73rmm2ZMuT8 +Message-ID: <CANEZrP25861JnOX-5zzZhRJJWAgUKoJsskGyUfw6XTKqE8qfdg@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Content-Type: multipart/alternative; boundary=089e013a100a6ebd3204e3e77731 +X-Spam-Score: 0.7 (/) +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.2 HTML_OBFUSCATE_10_20 BODY: Message is 10% to 20% HTML obfuscation + 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: 1V9a9o-0007jW-Uf +Subject: [Bitcoin-development] bitcoinj 0.10 +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: Wed, 14 Aug 2013 12:26:34 -0000 + +--089e013a100a6ebd3204e3e77731 +Content-Type: text/plain; charset=UTF-8 + +Hello, + +I'm pleased to announce version 0.10 of bitcoinj, a Java library for +writing Bitcoin applications. BitcoinJ has been used to create everything +from end-user wallet apps to network crawlers to SatoshiDice. + +To learn how to obtain bitcoinj 0.10, please see the following page: + + https://code.google.com/p/bitcoinj/wiki/UsingMaven + +The v0.10 release is signed by Andreas Schildbach's GPG key. The git hash +of the release is 777e6781d789. This paragraph is signed by the same +Bitcoin key as with previous releases (check their release announcements to +establish continuity). + +Signature: H9Nl7FPnmrUOmjhUZ0+xB4YW3q5F5gIkGdvllsDWmWYvOkNQHAE9jZE0I/qE1VfLPeMV+Rzo7geTB43uDSFSMek= + +*New in this release* + + - An implementation of *micropayment channels* was added. There have + been many bugfixes and improvements since the first announcement. This + feature allows you to set up a 1:1 payment relationship with a remote + server and after a short setup process send very tiny payments, very + rapidly. It's suitable for metered billing applications. An article, + "Working with micropayments" explains how to use it. This work was a joint + effort between Matt and myself. + - A simple sublibrary has been added that provides async IO based + client/server classes that transmit length prefixed protocol buffers. + - Thanks to Matija Mazi, some classes have been added that implement *the + BIP 32 deterministic wallet algorithm*. Note that these classes are not + yet used elsewhere in the system and full deterministic wallet support is + therefore not available, however, a low level API is available for + experimentation. That API is very likely to change in future releases so + don't get too attached to it. + - Thanks to Gary Rowe, we have integrated *a new Maven plugin* that + checks the SHA1 hashes of downloaded dependencies against a hard-coded + list. This means that even if an upstream Maven repository or developer + were to be compromised, library dependencies could not be switched out for + corrupted versions without someone noticing. For 0.10 the dependency hashes + were just initialised based on what was already downloaded. In future, + reproducible builds of upstream dependencies and auditing of changes would + provide better security. You can and should use Gary's +plugin<https://github.com/gary-rowe/BitcoinjEnforcerRules> in + your own projects to defend against a possible compromise of the bitcoinj + repository. + - *Callback handling* has been much improved. Each event listener can + have an Executor specified which takes responsibility for running the + callback. If you don't specify one they run by default on a single + background thread, the "user thread", instead of the origin framework + threads. This means your callbacks no longer need to be thread safe as + they're always run serially. You can also change the default executor if + you would like to control the thread on which callbacks run, for example to + marshal them into your GUI toolkit thread automatically. This fixes some of + the most painful parts of the pre-0.10 API, for instance that transaction + confidence listeners were not allowed to re-enter the library. + - *Exception handling* has also improved. You can assign a global + Thread.UncaughtExceptionHandler which receives any exceptions thrown on + the user thread (i.e. by your own event listeners), as well as any internal + exceptions thrown by network threads (like inability to parse a message + sent by a remote peer). Because your listeners now run on a separate thread + by default, you can no longer accidentally cause internal data corruption + or prevent other callbacks from running by leaking exceptions out of your + callbacks; a subtle knife-edge in the previous API. + - Support for *automatic wallet key rotation* has been added. + - We now require Bloom-capable (0.8+) peers by default and will + disconnect from older nodes. This avoids accidental bandwidth saturation on + mobile devices. + - The wallet now accepts timelocked transactions if it created them + itself. + - The wallet can be told to empty itself out, in which case the fee will + be subtracted from the total amount instead of added. This simplifies the + common case of wanting to send your entire balance whilst still including a + fee. + - Some JNI peers for event listeners were added. Auto-generated JNI + bindings are experimental and not yet merged in to the mainline codebase: + for now they are available as part of a separate project on github. This + work allows you to access the bitcoinj API using relatively natural looking + C++ code and an embedded JVM. + - You can now register custom PeerFilterProvider implementors to add + things to Bloom filters that aren't necessarily in wallets. + - We have begun adding nullity annotations to the API. Combined with a + strong static analysis engine like FindBugs or the IntelliJ Inspector, you + can find cases where you aren't handling possible null pointers. Note that + you should configure your static analysis system to understand the Guava + Preconditions assertions, as otherwise you will get false positives. + - You can now control how much information Wallet toString() dumps + contain more precisely. Extensions can contribute to a wallets debug dump + as well, and transaction data is now optional. + - Documentation: The getting started tutorial and PingService example + were rewritten. New articles were added that cover optimising chain sync + and using the library from non-Java languages. Existing articles were also + extended and refreshed. + - Many bug fixes and new methods. You should upgrade as soon as possible + to get the bug fixes, in particular, one that could cause transactions + inside the same block to be incorrectly re-ordered when using Bloom + filtering (which can affect the wallet). The library code now has more + internal annotations to help static analysis engines, and several bugs were + fixed as a result of that. + +*API Changes* + + - The ScriptBuilder class now takes TransactionSignature objects, these + wrap a raw ECDSA signature and the SIGHASH flags together, with utility + methods to work with them. + - The Locks class has been renamed to Threading. The thread on which + callbacks run has been changed, see above. + - The WalletEventListener.onKeyAdded method became onKeysAdded and now + takes a list, to make processing of bulk adds more efficient. + - BitcoinURIParseException is now checked so you can't forget to handle + bogus URIs. + - The Wallet.toString(..) method has additional parameters now so you + can control what is included in the dump. + +*Known issues* +* +* +Please see the limitations and missing +features<https://code.google.com/p/bitcoinj/wiki/Limitations> page. +This page has been fleshed out since the last release with common issues +and missing features. A few issues were also fixed and removed. + +--089e013a100a6ebd3204e3e77731 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hello,<div><br></div><div>I'm pleased to announce vers= +ion 0.10 of bitcoinj, a Java library for writing Bitcoin applications.=C2= +=A0<span style=3D"font-family:Arial,Helvetica,sans-serif;font-size:13px">Bi= +tcoinJ has been used to create everything from end-user wallet apps to netw= +ork crawlers to SatoshiDice.</span></div> +<div><span style=3D"font-family:Arial,Helvetica,sans-serif;font-size:13px">= +<br></span></div><div><span style=3D"font-family:Arial,Helvetica,sans-serif= +;font-size:13px">To learn how to obtain bitcoinj 0.10, please see the follo= +wing page:</span></div> +<div><span style=3D"font-family:Arial,Helvetica,sans-serif;font-size:13px">= +<br></span></div><div>=C2=A0 =C2=A0<a href=3D"https://code.google.com/p/bit= +coinj/wiki/UsingMaven" target=3D"_blank">https://code.google.com/p/bitcoinj= +/wiki/UsingMaven</a><span style=3D"font-family:Arial,Helvetica,sans-serif;f= +ont-size:13px"><br> +</span></div><div><br></div><div>The v0.10 release is signed by Andreas Sch= +ildbach's GPG key. The git hash of the release is 777e6781d789. This pa= +ragraph is signed by the same Bitcoin key as with previous releases (check = +their release announcements to establish continuity).</div> +<div><br></div><div>Signature:=C2=A0H9Nl7FPnmrUOmjhUZ0+xB4YW3q5F5gIkGdvllsD= +WmWYvOkNQHAE9jZE0I/qE1VfLPeMV+Rzo7geTB43uDSFSMek=3D</div><div><br></div><di= +v><b>New in this release</b></div><div><ul style=3D"padding-left:25px;max-w= +idth:62em;font-size:12.800000190734863px;font-family:arial,sans-serif"> +<li style=3D"margin-bottom:0.3em">An implementation of=C2=A0<b>micropayment= + channels</b>=C2=A0was added. There have been many bugfixes and improvement= +s since the first announcement. This feature allows you to set up a 1:1 pay= +ment relationship with a remote server and after a short setup process send= + very tiny payments, very rapidly. It's suitable for metered billing ap= +plications. An article, "Working with micropayments" explains how= + to use it. This work was a joint effort between Matt and myself.</li> +<li style=3D"margin-bottom:0.3em">A simple sublibrary has been added that p= +rovides async IO based client/server classes that transmit length prefixed = +protocol buffers.</li><li style=3D"margin-bottom:0.3em">Thanks to Matija Ma= +zi, some classes have been added that implement=C2=A0<b>the BIP 32 determin= +istic wallet algorithm</b>. Note that these classes are not yet used elsewh= +ere in the system and full deterministic wallet support is therefore not av= +ailable, however, a low level API is available for experimentation. That AP= +I is very likely to change in future releases so don't get too attached= + to it.</li> +<li style=3D"margin-bottom:0.3em">Thanks to Gary Rowe, we have integrated= +=C2=A0<b>a new Maven plugin</b>=C2=A0that checks the SHA1 hashes of downloa= +ded dependencies against a hard-coded list. This means that even if an upst= +ream Maven repository or developer were to be compromised, library dependen= +cies could not be switched out for corrupted versions without someone notic= +ing. For 0.10 the dependency hashes were just initialised based on what was= + already downloaded. In future, reproducible builds of upstream dependencie= +s and auditing of changes would provide better security. You can and should= + use=C2=A0<a href=3D"https://github.com/gary-rowe/BitcoinjEnforcerRules" ta= +rget=3D"_blank">Gary's plugin</a>=C2=A0in your own projects to defend a= +gainst a possible compromise of the bitcoinj repository.</li> +<li style=3D"margin-bottom:0.3em"><b>Callback handling</b>=C2=A0has been mu= +ch improved. Each event listener can have an=C2=A0<tt style=3D"font-family:= +Monaco,'DejaVu Sans Mono','Bitstream Vera Sans Mono','L= +ucida Console',monospace;font-size:12px;max-width:66em">Executor</tt>= +=C2=A0specified which takes responsibility for running the callback. If you= + don't specify one they run by default on a single background thread, t= +he "user thread", instead of the origin framework threads. This m= +eans your callbacks no longer need to be thread safe as they're always = +run serially. You can also change the default executor if you would like to= + control the thread on which callbacks run, for example to marshal them int= +o your GUI toolkit thread automatically. This fixes some of the most painfu= +l parts of the pre-0.10 API, for instance that transaction confidence liste= +ners were not allowed to re-enter the library.</li> +<li style=3D"margin-bottom:0.3em"><b>Exception handling</b>=C2=A0has also i= +mproved. You can assign a global=C2=A0<tt style=3D"font-family:Monaco,'= +DejaVu Sans Mono','Bitstream Vera Sans Mono','Lucida Consol= +e',monospace;font-size:12px;max-width:66em">Thread.UncaughtExceptionHan= +dler</tt>=C2=A0which receives any exceptions thrown on the user thread (i.e= +. by your own event listeners), as well as any internal exceptions thrown b= +y network threads (like inability to parse a message sent by a remote peer)= +. Because your listeners now run on a separate thread by default, you can n= +o longer accidentally cause internal data corruption or prevent other callb= +acks from running by leaking exceptions out of your callbacks; a subtle kni= +fe-edge in the previous API.</li> +<li style=3D"margin-bottom:0.3em">Support for=C2=A0<b>automatic wallet key = +rotation</b>=C2=A0has been added.</li><li style=3D"margin-bottom:0.3em">We = +now require Bloom-capable (0.8+) peers by default and will disconnect from = +older nodes. This avoids accidental bandwidth saturation on mobile devices.= +</li> +<li style=3D"margin-bottom:0.3em">The wallet now accepts timelocked transac= +tions if it created them itself.</li><li style=3D"margin-bottom:0.3em">The = +wallet can be told to empty itself out, in which case the fee will be subtr= +acted from the total amount instead of added. This simplifies the common ca= +se of wanting to send your entire balance whilst still including a fee.</li= +> +<li style=3D"margin-bottom:0.3em">Some JNI peers for event listeners were a= +dded. Auto-generated JNI bindings are experimental and not yet merged in to= + the mainline codebase: for now they are available as part of a separate pr= +oject on github. This work allows you to access the bitcoinj API using rela= +tively natural looking C++ code and an embedded JVM.</li> +<li style=3D"margin-bottom:0.3em">You can now register custom=C2=A0<tt styl= +e=3D"font-family:Monaco,'DejaVu Sans Mono','Bitstream Vera Sans= + Mono','Lucida Console',monospace;font-size:12px;max-width:66em= +">PeerFilterProvider</tt>=C2=A0implementors to add things to Bloom filters = +that aren't necessarily in wallets.</li> +<li style=3D"margin-bottom:0.3em">We have begun adding nullity annotations = +to the API. Combined with a strong static analysis engine like FindBugs or = +the IntelliJ Inspector, you can find cases where you aren't handling po= +ssible null pointers. Note that you should configure your static analysis s= +ystem to understand the Guava Preconditions assertions, as otherwise you wi= +ll get false positives.</li> +<li style=3D"margin-bottom:0.3em">You can now control how much information = +Wallet toString() dumps contain more precisely. Extensions can contribute t= +o a wallets debug dump as well, and transaction data is now optional.</li> +<li style=3D"margin-bottom:0.3em">Documentation: The getting started tutori= +al and PingService example were rewritten. New articles were added that cov= +er optimising chain sync and using the library from non-Java languages. Exi= +sting articles were also extended and refreshed.</li> +<li style=3D"margin-bottom:0.3em">Many bug fixes and new methods. You shoul= +d upgrade as soon as possible to get the bug fixes, in particular, one that= + could cause transactions inside the same block to be incorrectly re-ordere= +d when using Bloom filtering (which can affect the wallet). The library cod= +e now has more internal annotations to help static analysis engines, and se= +veral bugs were fixed as a result of that.</li> +</ul><p style=3D"line-height:1.25em;max-width:64em;font-size:12.80000019073= +4863px;font-family:arial,sans-serif"><b>API Changes</b></p><ul style=3D"pad= +ding-left:25px;max-width:62em;font-size:12.800000190734863px;font-family:ar= +ial,sans-serif"> +<li style=3D"margin-bottom:0.3em">The=C2=A0<tt style=3D"font-family:Monaco,= +'DejaVu Sans Mono','Bitstream Vera Sans Mono','Lucida C= +onsole',monospace;font-size:12px;max-width:66em">ScriptBuilder</tt>=C2= +=A0class now takes=C2=A0<tt style=3D"font-family:Monaco,'DejaVu Sans Mo= +no','Bitstream Vera Sans Mono','Lucida Console',monospa= +ce;font-size:12px;max-width:66em">TransactionSignature</tt>=C2=A0objects, t= +hese wrap a raw ECDSA signature and the SIGHASH flags together, with utilit= +y methods to work with them.</li> +<li style=3D"margin-bottom:0.3em">The=C2=A0<tt style=3D"font-family:Monaco,= +'DejaVu Sans Mono','Bitstream Vera Sans Mono','Lucida C= +onsole',monospace;font-size:12px;max-width:66em">Locks</tt>=C2=A0class = +has been renamed to=C2=A0<tt style=3D"font-family:Monaco,'DejaVu Sans M= +ono','Bitstream Vera Sans Mono','Lucida Console',monosp= +ace;font-size:12px;max-width:66em">Threading</tt>. The thread on which call= +backs run has been changed, see above.</li> +<li style=3D"margin-bottom:0.3em">The=C2=A0<tt style=3D"font-family:Monaco,= +'DejaVu Sans Mono','Bitstream Vera Sans Mono','Lucida C= +onsole',monospace;font-size:12px;max-width:66em">WalletEventListener.on= +KeyAdded</tt>=C2=A0method became=C2=A0<tt style=3D"font-family:Monaco,'= +DejaVu Sans Mono','Bitstream Vera Sans Mono','Lucida Consol= +e',monospace;font-size:12px;max-width:66em">onKeysAdded</tt>=C2=A0and n= +ow takes a list, to make processing of bulk adds more efficient.</li> +<li style=3D"margin-bottom:0.3em"><tt style=3D"font-family:Monaco,'Deja= +Vu Sans Mono','Bitstream Vera Sans Mono','Lucida Console= +9;,monospace;font-size:12px;max-width:66em">BitcoinURIParseException</tt>= +=C2=A0is now checked so you can't forget to handle bogus URIs.</li> +<li style=3D"margin-bottom:0.3em">The=C2=A0<tt style=3D"font-family:Monaco,= +'DejaVu Sans Mono','Bitstream Vera Sans Mono','Lucida C= +onsole',monospace;font-size:12px;max-width:66em">Wallet.toString(..)</t= +t>=C2=A0method has additional parameters now so you can control what is inc= +luded in the dump.</li> +</ul></div><div><b>Known issues</b></div><div><b><br></b></div><div>Please = +see the=C2=A0<a href=3D"https://code.google.com/p/bitcoinj/wiki/Limitations= +" target=3D"_blank">limitations and missing features</a>=C2=A0page. This pa= +ge has been fleshed out since the last release with common issues and missi= +ng features. A few issues were also fixed and removed.</div> +</div> + +--089e013a100a6ebd3204e3e77731-- + + |