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" 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 > . > > 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. > > > > > ------------------------------------------------------------------------------ > 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 > >