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.
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ 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
