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