Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 [ANN] bitcoinj 0.7 released February 19, 2013, 10:29:03 PM #1



To get bitcoinj 0.7, check out our source from git and then run git reset --hard a9bd8631b904. This will place you on the 0.7 release in a secure manner. This paragraph was written on Tuesday 19th February 2013 and is signed with the following key, which will be used in all release announcements in future: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m.



Signature for the last paragraph: IMvY1FsQobjU2t83ztQL3CTA+V+7WWKBFwMC+UWKCOMyTKA+73iSsFnCHdbFjAOEFMQH/NvJMTgGeVCSV/F9hfs=



If you want to, you can check that the original announcement mail sent to



Release notes



Thanks to Matt Corallo, we now support a fully verifying mode in addition to simplified verification. This is a tremendous amount of work that wouldn't have happened without Matt! Right now, we strongly discourage anyone from using it for mining (which is not supported out of the box anyway). Use it in a production environment only if you know what you're doing and are willing to risk losing money. If you do use it, let us know so we can contact you when problems are discovered. Read the documentation carefully before you begin.

Also thanks to Matt, Bloom filtering is now implemented and activated by default. When bitcoinj connects to a peer that supports Bloom filtering, only transactions relevant to the wallet will be downloaded which makes bandwidth usage scale with the size of your wallet, not global system activity. A configurable false positive ratio allows you to trade off bandwidth vs privacy. App developers don't need to do anything to take advantage of this, it is enabled automatically.

PeerGroup now pings its peers and calculates moving averages of the ping times. Ping time, versions and block heights are taken into account when selecting the peer to download the chain from.

You can now customize which outputs the wallet uses to create spends. The new default coin selector object allows you to spend unconfirmed change as long as it's been seen propagating across the network, addressing a common end-user pain point in wallet apps.

Optimized networking code for faster startup.

A new PeerMonitor example app shows how to put properties of connected peers into a GUI.

The Wallet is now decoupled from the BlockChain using the new BlockChainListener interface. This will simplify the development of some apps that want to process transactions but not maintain an actual wallet.

The dependencies of broadcast transactions are now downloaded and risk analyzed. At the moment they are only being checked for having a timelock. In future we may also analyze tree depth. The goal is to make certain kinds of protocol abuse harder. Wallets will reject timelocked transactions by default, this can be overridden via a property.

You can now create timelocked transactions with WalletTool if you want to.

Compressed public keys are now used by default.

Support testnet3

Support bitcoin-qt compatible message signing and verification.

ECDSA key recovery is now implemented and allows you to obtain the public key from an extended signature. If the signature is not extended then there are multiple key possibilities returned.

Many bugfixes and minor improvements

API changes:



ECKey.sign() now takes a Sha256Hash as an argument and returns an ECDSASignature object in response. To get DER encoded signatures, use the encodeToDER() method of ECDSASignature.

ECKey.publicKeyFromPrivate now takes an additional compressed parameter.

PeerGroup.start()/PeerGroup.shutDown() now run asynchronously and return futures you can use to wait for them. You cannot restart a PeerGroup once it has been shut down any more.

Credits



Thanks to Matt Corallo (a.k.a. BlueMatt) for his huge contributions to this release.



As always, thanks to Andreas Schildbach for his thorough testing, ideas and high volume of quality bug reports. Also thanks to Jim Burton for the same reasons.



Finally thanks to Ben (piuk) of blockchain.info for funding the ECDSA key recovery feature.[/list] I'm pleased to announce the release of version 0.7 of the bitcoinj Java library for working with Bitcoin. Bitcoinj forms the foundation of MultiBit, Bitcoin Wallet for Android, SatoshiDice and more.To get bitcoinj 0.7, check out our source from git and then run git reset --hard a9bd8631b904. This will place you on the 0.7 release in a secure manner. This paragraph was written on Tuesday 19th February 2013 and is signed with the following key, which will be used in all release announcements in future: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m.Signature for the last paragraph: IMvY1FsQobjU2t83ztQL3CTA+V+7WWKBFwMC+UWKCOMyTKA+73iSsFnCHdbFjAOEFMQH/NvJMTgGeVCSV/F9hfs=If you want to, you can check that the original announcement mail sent to bitcoinj@googlegroups.com is correctly signed with the google.com DKIM key, to establish a full chain of trust.API changes:Thanks to Matt Corallo (a.k.a. BlueMatt) for his huge contributions to this release.As always, thanks to Andreas Schildbach for his thorough testing, ideas and high volume of quality bug reports. Also thanks to Jim Burton for the same reasons.Finally thanks to Ben (piuk) of blockchain.info for funding the ECDSA key recovery feature.[/list]

AWARD-WINNING

CASINO CRYPTO EXCLUSIVE

CLUBHOUSE 1500+

GAMES 2 MIN

CASH-OUTS 24/7

SUPPORT 100s OF

FREE SPINS PLAY NOW tised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here. Advertised sites are not endorseby the Bitcoin Forum. They may beunsafe, untrustworthy, or illegal in your jurisdiction.

TierNolan



Offline



Activity: 1232

Merit: 1006







LegendaryActivity: 1232Merit: 1006 Re: [ANN] bitcoinj 0.7 released February 20, 2013, 01:17:30 AM #3 You mention on your site that the new "full node" operation is very likely to have hard-fork bugs. Do you think that is a permanent situation?



Apparently, the official rule is that a chain is correct if the reference client says it is correct.



I wonder if the creation of some block-chain serialization format would be appropriate. This could be combined with a verifier.



This would be a much shorter program than an entire client that needs to deal with networking.



Maybe that could be vetted into some kind of semi-official spec.



Probably all the blocks, one after another, in the same format as the network protocol, is sufficient, so maybe I am over-thinking it. 1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: [ANN] bitcoinj 0.7 released February 20, 2013, 10:50:45 AM #4 No, it's not a permanent situation. The level of effort taken to find and eliminate all hard-forking bugs is large but finite. If there's enough interest (and Matt seems very interested) then eventually we'll have a high degree of confidence in the correctness of the code, at least to the point where emergency security scrambles are no more common than for any other kind of software.

TierNolan



Offline



Activity: 1232

Merit: 1006







LegendaryActivity: 1232Merit: 1006 Re: [ANN] bitcoinj 0.7 released February 20, 2013, 11:32:56 AM #5 Quote from: Mike Hearn on February 20, 2013, 10:50:45 AM No, it's not a permanent situation. The level of effort taken to find and eliminate all hard-forking bugs is large but finite. If there's enough interest (and Matt seems very interested) then eventually we'll have a high degree of confidence in the correctness of the code, at least to the point where emergency security scrambles are no more common than for any other kind of software.



What you be your view of splitting off the "validator" as a separate project that is included, so separate from the network code?



That way all java clients could use the same block chain validator. What you be your view of splitting off the "validator" as a separate project that is included, so separate from the network code?That way all java clients could use the same block chain validator. 1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: [ANN] bitcoinj 0.7 released February 20, 2013, 12:05:42 PM #7 Quote from: TierNolan on February 20, 2013, 11:32:56 AM What you be your view of splitting off the "validator" as a separate project that is included, so separate from the network code?



That way all java clients could use the same block chain validator.



I don't understand your proposal I'm afraid. The networking code is already a separate group of classes. Switching from SPV mode to full mode means instantiating a couple of different classes and plugging them into the rest, but the code is modular enough already. I don't understand your proposal I'm afraid. The networking code is already a separate group of classes. Switching from SPV mode to full mode means instantiating a couple of different classes and plugging them into the rest, but the code is modular enough already.

TierNolan



Offline



Activity: 1232

Merit: 1006







LegendaryActivity: 1232Merit: 1006 Re: [ANN] bitcoinj 0.7 released February 20, 2013, 12:10:41 PM #8 Quote from: Mike Hearn on February 20, 2013, 12:05:42 PM I don't understand your proposal I'm afraid. The networking code is already a separate group of classes. Switching from SPV mode to full mode means instantiating a couple of different classes and plugging them into the rest, but the code is modular enough already.



Sounds like you already did it. I was thinking of a specific library that other projects could include in the maven pom.xml files, so there is 1 central java reference for how to do validation. Sounds like you already did it. I was thinking of a specific library that other projects could include in the maven pom.xml files, so there is 1 central java reference for how to do validation. 1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: [ANN] bitcoinj 0.7 released February 20, 2013, 12:18:43 PM #9 Yeah, bitcoinj is that library. You can refer to it from your POM, instantiate a few objects and you're done. Look at the docs on the website for examples.



Currently we don't upload to Maven Central. The problem is, it doesn't seem to have any security features, and compromising Maven Central then swapping out bitcoinj for a backdoored copy would be a superb way to steal peoples wallets. Extending Maven to support specifying the hashes of the dependencies along with their names and versions would be a good solution, but nobody has done it yet. Until then you need to use git and check out the code by hand.

