[Bitcoin-development] bitcoinj 0.12

[Bitcoin-development] bitcoinj 0.12

[Mike Hearn]

[-- Attachment #1.1: Type: text/plain, Size: 8198 bytes --]

I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most popular Bitcoin libraries. It is used by at least four Android wallets, three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp, Lighthouse, BlueMatt’s relay network, bitpos, countless alt coin wallets, for academic research projects and much more.

This release represents 8 months of work. The biggest new feature is HD wallets. Other notable enhancements include a bundled Tor client that can be activated with one line of code, support for multisig wallets, much faster and deterministic ECDSA, many API improvements and big upgrades to the included GUI wallet which can be seen in a new screencasted tutorial.

The commit hash of bitcoinj 0.12 is 83a9a71f3fff3f223d0737ad758b519a39dbbd62. 

New in this release

Privacy enhancements:
Wallets are now hierarchical and deterministic (HD) by default, using the BIP32 specification. Support for mnemonic codes (BIP 39) is also included. Change and receive addresses are no longer being reused. Old wallets are upgraded in place using the private key of the oldest non-rotating key as the seed bytes, so old backups remain valid.
Thanks to devrandom, we have an integrated Tor mode using the Orchid library. The user does not have to install the Tor client as it’s all pure Java. WalletAppKit users can enable usage of Tor with a single line of code. This support should be considered experimental for now.
Thanks to Kosta Korenkov, we have an experimental multisig wallets implementation. Multisig (also “married”) wallets are HD wallets that are connected to a third party risk analysis service or device. When married, the wallet tracks multiple BIP32 key trees, keeps them in sync and starts vending P2SH addresses.
As part of this work, transaction signing is now pluggable. TransactionSigner implementations can be added to the wallet and will be serialized into and out of the users saved wallet file. Signers are given a transaction to sign in sequence. This is intended for risk analysis providers to provide a class that talks to their server to get a signature of the right form, so that all bitcoinj based wallets can be easily upgraded to support the new provider.
Reject messages are now deserialized and logged, though not yet exposed in the API.
Upgraded to Guava 16 and Bouncy Castle 1.51. Thanks to Peter Dettman and the rest of the Bouncy Castle team, bitcoinj now uses deterministic ECDSA for signing and we’re now using an accelerated secp256k1 implementation that exploits the special properties of this curve, for dramatically faster calculations.
Payment protocol code improvements: Some X.509 utility code was refactored out of PaymentSession for general usage. StartCom was added to the default trust store which was promoted to override the system trust store on non-Android platforms. A command line tool to dump requests to stdout was added.
Thanks to Andreas Schildbach:
We are now BIP62 (canonical push encodings) compliant.
A new Coin class replaces usage of BigInteger for marking values that are quantities of bitcoin. Formatting has moved into the new MonetaryFormat class.
The wallet now saves the fee paid on transactions we calculated ourselves. This is useful for putting it into a wallet user interface.
Transactions can have user memos and exchange rates attached, that will be saved by the wallet.
Support for decrypting BIP 38 protected private keys has been added.
Checkpoints can now be stored textually as well as in the old binary format.
There is also a new BtcFormat API that provides an alternative to MonetaryFormat that plugs in to the java.text framework.
Added new DNS seed from Addy Yeow.
Wallets can now have string->byte[] mappings attached to them, for lighter weight extensions.
Thanks to Richard Green, there is now a Python version of the ForwardingService program from the getting started tutorial. This shows how to use bitcoinj from Python using the Jython interpreter.
bitcoinj now probes localhost for a Bitcoin node and automatically uses that instead of the P2P network, when present. This means any bitcoinj based app can be easily upgraded from SPV to full security just by running Core at the same time: no setup needed.
Thanks to Michael Bumann, there are now more example apps showing how to use parts of the API.
WalletTemplate/WalletAppKit improvements. WalletTemplate is a demo app that shows how to create a cross-platform GUI wallet with a modern style and 60fps animations. WalletAppKit is a very high level API for creating apps that have a Bitcoin wallet:
Now supports mnemonic code and restore from seed words. A date picker is provided to cut down on the amount of chain that needs to be rescanned.
Support for encrypting wallets. Password is requested when needed. The difficulty of the scrypt function is selected to always take a fixed number of seconds even if hardware gets more powerful.
Some new animation and utility code backported from Lighthouse.
Tor support
Thanks to Martin Zachrison, the micropayment channels implementation has received various improvements.
Thanks to Eric Tierney (Circle), the Postgres store can now take a custom schema.
The Bloom filtering API has been extended so FilteredBlock objects can now be produced from Block objects given a BloomFilter. Previously there was support for client-side Bloom usage but no implementation of the generation part.
Many other bugfixes, cleanups, minor tweaks and small new APIs.
Documentation and tutorials

A JavaScript tutorial has been added, showing how to use bitcoinj from this language. More tutorials in other languages will come in future.
The “Working with the wallet” document has been significantly extended to cover encryption, watching wallets, HD wallets and multisig/married wallets.
A new document and accompanying screencast shows how to extend the WalletTemplate app to have a transactions list, and then make a native/bundled packages that don’t need the user to install Java. By following this tutorial you will learn how to make a basic cross platform desktop wallet of your own.
All other docs were refreshed to the latest APIs.
API changes

The package name has changed to org.bitcoinj and the core Maven artifact name is now “bitcoinj-core”. You can auto-port most of your code by running find . -name '*.java' \| xargs sed -i .bak 's/com.google.bitcoin./import org.bitcoinj./g
Wallet.completeTx now throws more precise unchecked exceptions in edge cases, instead of IllegalArgumentException.
The use of BigInteger to represent quantities of Bitcoin has been replaced with the more efficient, type safe and useful class Coin. Coin is mostly source compatible with BigInteger so you can probably just do a search and replace to update your codebase. Utils.bitcoinValueToFriendlyString and friends moved to CoinFormat.
NetworkParameters.getProofOfWorkLimit was renamed to getMaxTarget for consistency with other Bitcoin codebases.
The library no longer uses the misleading term “nanocoins” to mean satoshis (the old term predated the use of the word satoshi to describe the smallest possible amount of bitcoin).
TransactionConfidence no longer tracks total work done.
Because outputs are now shuffled any code during that assumes the ordering is preserved will break. You can set the shuffleOutputs field of SendRequest to false to disable this behaviour if you need to.
The ECKey and HD API’s have changed quite a bit: several constructors were replaced with clearer static factory methods that make it more obvious how their parameters are interpreted. The new methods don’t change their behaviour depending on the pattern of nulls passed into them.
Some unit testing utilities have been moved to the new testing subpackage and cleaned up/rearranged. It should be easier to write unit tests for your app that need a simulated network now. DeterministicKey now derives from ECKey.
We now use Utils.HEX.encode() and Utils.HEX.decode() to do translation to and from base 16.
Transaction.hashTransactionForSignature was renamed to just hashForSignature.
The subVer string sent by bitcoinj now has a lower cased first component.


[-- Attachment #1.2: Type: text/html, Size: 12592 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3927 bytes --]

Re: [Bitcoin-development] bitcoinj 0.12

[Pavol Rusnak]

On 10/03/2014 02:49 PM, Mike Hearn wrote:
> I’m pleased to announce version 0.12 of bitcoinj
> 
> This release represents 8 months of work. The biggest new feature is HD wallets.

Congratulations on this release and I am quite happy that bitcoinj now
fully supports BIP32 and BIP39!

Does it also support various HD wallet structures such as BIP44 for example?

-- 
Best Regards / S pozdravom,

Pavol Rusnak <stick@gk2.sk>

Re: [Bitcoin-development] bitcoinj 0.12

[Wladimir]

On Fri, Oct 3, 2014 at 2:49 PM, Mike Hearn <mike@plan99.net> wrote:
> I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most
> popular Bitcoin libraries. It is used by at least four Android wallets,
> three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp,
> Lighthouse, BlueMatt’s relay network, bitpos, countless alt coin wallets,
> for academic research projects and much more.

Congrats on the release!

Wladimir

Re: [Bitcoin-development] bitcoinj 0.12

[Tom Harding]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]


I'm stunned by what bitcoinj can do these days.  Just reading the 
release notes gives one app ideas.  Mike, Awesome.


On 10/3/2014 5:49 AM, Mike Hearn wrote:
> I'm pleased to announce version 0.12 of bitcoinj, one of the worlds 
> most popular Bitcoin libraries.


[-- Attachment #2: Type: text/html, Size: 759 bytes --]

Re: [Bitcoin-development] bitcoinj 0.12

[Kristov Atlas]

[-- Attachment #1: Type: text/plain, Size: 10491 bytes --]

Congrats, and thanks for your hard work.

I hate to reply to a release that includes a huge number of new features
with yet another feature request, so -- with apologies -- any plans for
bitcoinj to support stealth address sending and/or receiving?

https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth

Sincerely,
Kristov Atlas
On Oct 3, 2014 8:50 AM, "Mike Hearn" <mike@plan99.net> wrote:

> I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most
> popular Bitcoin libraries. It is used by at least four Android wallets,
> three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp,
> Lighthouse, BlueMatt’s relay network, bitpos, countless alt coin wallets,
> for academic research projects and much more.
>
> This release represents 8 months of work. The biggest new feature is HD
> wallets. Other notable enhancements include a bundled Tor client that can
> be activated with one line of code, support for multisig wallets, much
> faster and deterministic ECDSA, many API improvements and big upgrades to
> the included GUI wallet which can be seen in a new screencasted tutorial
> <https://bitcoinj.github.io/simple-gui-wallet>.
>
> The commit hash of bitcoinj 0.12
> is 83a9a71f3fff3f223d0737ad758b519a39dbbd62.
>
> New in this release
>
>    - Privacy enhancements:
>       - Wallets are now hierarchical and deterministic (HD) by default,
>       using the BIP32 specification. Support for mnemonic codes (BIP 39) is also
>       included. Change and receive addresses are no longer being reused. Old
>       wallets are upgraded in place using the private key of the oldest
>       non-rotating key as the seed bytes, so old backups remain valid.
>       - Thanks to devrandom, we have an integrated Tor mode using the
>       Orchid library. The user does not have to install the Tor client as it’s
>       all pure Java. WalletAppKit users can enable usage of Tor with a single
>       line of code. This support should be considered experimental for now.
>    - Thanks to Kosta Korenkov, we have an experimental multisig wallets
>    implementation. Multisig (also “married”) wallets are HD wallets that are
>    connected to a third party risk analysis service or device. When married,
>    the wallet tracks multiple BIP32 key trees, keeps them in sync and starts
>    vending P2SH addresses.
>       - As part of this work, transaction signing is now pluggable.
>       TransactionSigner implementations can be added to the wallet and will be
>       serialized into and out of the users saved wallet file. Signers are given a
>       transaction to sign in sequence. This is intended for risk analysis
>       providers to provide a class that talks to their server to get a signature
>       of the right form, so that all bitcoinj based wallets can be easily
>       upgraded to support the new provider.
>    - Reject messages are now deserialized and logged, though not yet
>    exposed in the API.
>    - Upgraded to Guava 16 and Bouncy Castle 1.51. Thanks to Peter Dettman
>    and the rest of the Bouncy Castle team, bitcoinj now uses deterministic
>    ECDSA for signing and we’re now using an accelerated secp256k1
>    implementation that exploits the special properties of this curve, for
>    dramatically faster calculations.
>    - Payment protocol code improvements: Some X.509 utility code was
>    refactored out of PaymentSession for general usage. StartCom was added to
>    the default trust store which was promoted to override the system trust
>    store on non-Android platforms. A command line tool to dump requests to
>    stdout was added.
>    - Thanks to Andreas Schildbach:
>       - We are now BIP62 (canonical push encodings) compliant.
>       - A new Coin class replaces usage of BigInteger for marking values
>       that are quantities of bitcoin. Formatting has moved into the new
>       MonetaryFormat class.
>       - The wallet now saves the fee paid on transactions we calculated
>       ourselves. This is useful for putting it into a wallet user interface.
>       - Transactions can have user memos and exchange rates attached,
>       that will be saved by the wallet.
>       - Support for decrypting BIP 38 protected private keys has been
>       added.
>       - Checkpoints can now be stored textually as well as in the old
>       binary format.
>    - There is also a new BtcFormat API that provides an alternative to
>    MonetaryFormat that plugs in to the java.text framework.
>    - Added new DNS seed from Addy Yeow.
>    - Wallets can now have string->byte[] mappings attached to them, for
>    lighter weight extensions.
>    - Thanks to Richard Green, there is now a Python version of the
>    ForwardingService program from the getting started tutorial. This shows how
>    to use bitcoinj from Python using the Jython interpreter.
>    - bitcoinj now probes localhost for a Bitcoin node and automatically
>    uses that instead of the P2P network, when present. This means any bitcoinj
>    based app can be easily upgraded from SPV to full security just by running
>    Core at the same time: no setup needed.
>    - Thanks to Michael Bumann, there are now more example apps showing
>    how to use parts of the API.
>    - WalletTemplate/WalletAppKit improvements. WalletTemplate is a demo
>    app that shows how to create a cross-platform GUI wallet with a modern
>    style and 60fps animations. WalletAppKit is a very high level API for
>    creating apps that have a Bitcoin wallet:
>       - Now supports mnemonic code and restore from seed words. A date
>       picker is provided to cut down on the amount of chain that needs to be
>       rescanned.
>       - Support for encrypting wallets. Password is requested when
>       needed. The difficulty of the scrypt function is selected to always take a
>       fixed number of seconds even if hardware gets more powerful.
>       - Some new animation and utility code backported from Lighthouse.
>       - Tor support
>    - Thanks to Martin Zachrison, the micropayment channels implementation
>    has received various improvements.
>    - Thanks to Eric Tierney (Circle), the Postgres store can now take a
>    custom schema.
>    - The Bloom filtering API has been extended so FilteredBlock objects
>    can now be produced from Block objects given a BloomFilter. Previously
>    there was support for client-side Bloom usage but no implementation of the
>    generation part.
>    - Many other bugfixes, cleanups, minor tweaks and small new APIs.
>
> *Documentation and tutorials*
>
>    - A JavaScript tutorial <https://bitcoinj.github.io/getting-started-js> has
>    been added, showing how to use bitcoinj from this language. More tutorials
>    in other languages will come in future.
>    - The “Working with the wallet
>    <https://bitcoinj.github.io/working-with-the-wallet>” document has
>    been significantly extended to cover encryption, watching wallets, HD
>    wallets and multisig/married wallets.
>    - A new document and accompanying screencast
>    <https://bitcoinj.github.io/simple-gui-wallet> shows how to extend the
>    WalletTemplate app to have a transactions list, and then make a
>    native/bundled packages that don’t need the user to install Java. By
>    following this tutorial you will learn how to make a basic cross platform
>    desktop wallet of your own.
>    - All other docs were refreshed to the latest APIs.
>
> *API changes*
>
>    - The package name has changed to org.bitcoinj and the core Maven
>    artifact name is now “bitcoinj-core”. You can auto-port most of your code
>    by running find . -name '*.java' \| xargs sed -i .bak
>    's/com.google.bitcoin./import org.bitcoinj./g
>    - Wallet.completeTx now throws more precise unchecked exceptions in
>    edge cases, instead of IllegalArgumentException.
>    - The use of BigInteger to represent quantities of Bitcoin has been
>    replaced with the more efficient, type safe and useful class Coin. Coin is
>    mostly source compatible with BigInteger so you can probably just do a
>    search and replace to update your codebase.
>    Utils.bitcoinValueToFriendlyString and friends moved to CoinFormat.
>    - NetworkParameters.getProofOfWorkLimit was renamed to getMaxTarget
>    for consistency with other Bitcoin codebases.
>    - The library no longer uses the misleading term “nanocoins” to mean
>    satoshis (the old term predated the use of the word satoshi to describe the
>    smallest possible amount of bitcoin).
>    - TransactionConfidence no longer tracks total work done.
>    - Because outputs are now shuffled any code during that assumes the
>    ordering is preserved will break. You can set the shuffleOutputs field of
>    SendRequest to false to disable this behaviour if you need to.
>    - The ECKey and HD API’s have changed quite a bit: several
>    constructors were replaced with clearer static factory methods that make it
>    more obvious how their parameters are interpreted. The new methods don’t
>    change their behaviour depending on the pattern of nulls passed into them.
>    - Some unit testing utilities have been moved to the new testing
>    subpackage and cleaned up/rearranged. It should be easier to write unit
>    tests for your app that need a simulated network now. DeterministicKey now
>    derives from ECKey.
>    - We now use Utils.HEX.encode() and Utils.HEX.decode() to do
>    translation to and from base 16.
>    - Transaction.hashTransactionForSignature was renamed to just
>    hashForSignature.
>    - The subVer string sent by bitcoinj now has a lower cased first
>    component.
>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 13730 bytes --]

Re: [Bitcoin-development] bitcoinj 0.12

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

Hey Kristov,

> I hate to reply to a release that includes a huge number of new features
> with yet another feature request, so -- with apologies -- any plans for
> bitcoinj to support stealth address sending and/or receiving?
>
Stealth addresses and SPV don't mix well, so no. I wrote up a description
of how to do something similar with the payment protocol here:

https://medium.com/@octskyward/ecdh-in-the-payment-protocol-cb2f81962c1b

Because you can send data around outside the block chain on private
channels, with the pp the same issues don't crop up.

At the moment there are no concrete plans what goes into the next release.
I will be focusing on fully launching Lighthouse and crowdfunding for
decentralisation/crypto related projects, so I won't be doing any major
feature work on bitcoinj. Luckily it's become quite an active project now
and there are lots of contributors, so things won't stand still.

If I were to tackle a big project the next one would not be privacy
related. It'd be refactoring the wallet so it doesn't store transactions
directly anymore, just unspent outputs. Bitcoinj has always been largely
driven by the needs of Andreas' mobile app, and right now the top user
reported problem there is people hitting the scalability limits of the
current design (e.g. they are mining directly into their phone's wallet).

[-- Attachment #2: Type: text/html, Size: 1865 bytes --]