Re: [Bitcoin-development] bitcoinj 0.12

[Kristov Atlas <kristovatlas.lists@gmail.com>]

[-- 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 --]