From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XaJ55-00035x-VX for bitcoin-development@lists.sourceforge.net; Sat, 04 Oct 2014 06:44:40 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.180 as permitted sender) client-ip=209.85.217.180; envelope-from=kristovatlas.lists@gmail.com; helo=mail-lb0-f180.google.com; Received: from mail-lb0-f180.google.com ([209.85.217.180]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XaJ53-0002ho-NR for bitcoin-development@lists.sourceforge.net; Sat, 04 Oct 2014 06:44:39 +0000 Received: by mail-lb0-f180.google.com with SMTP id f15so2078426lbj.11 for ; Fri, 03 Oct 2014 23:44:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.25.65 with SMTP id a1mr966557lbg.85.1412405071010; Fri, 03 Oct 2014 23:44:31 -0700 (PDT) Received: by 10.152.195.69 with HTTP; Fri, 3 Oct 2014 23:44:30 -0700 (PDT) Received: by 10.152.195.69 with HTTP; Fri, 3 Oct 2014 23:44:30 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 Oct 2014 02:44:30 -0400 Message-ID: From: Kristov Atlas To: Mike Hearn Content-Type: multipart/alternative; boundary=001a11c3e92089601d0504932e3f X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (kristovatlas.lists[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XaJ53-0002ho-NR Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bitcoinj 0.12 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 06:44:40 -0000 --001a11c3e92089601d0504932e3f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=E2=80=99m pleased to announce version 0.12 of bitcoinj, one of the worl= ds most > popular Bitcoin libraries. It is used by at least four Android wallets, > three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp, > Lighthouse, BlueMatt=E2=80=99s 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=E2=80=99s > all pure Java. WalletAppKit users can enable usage of Tor with a si= ngle > line of code. This support should be considered experimental for no= w. > - Thanks to Kosta Korenkov, we have an experimental multisig wallets > implementation. Multisig (also =E2=80=9Cmarried=E2=80=9D) wallets are = HD wallets that are > connected to a third party risk analysis service or device. When marri= ed, > the wallet tracks multiple BIP32 key trees, keeps them in sync and sta= rts > vending P2SH addresses. > - As part of this work, transaction signing is now pluggable. > TransactionSigner implementations can be added to the wallet and wi= ll 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 si= gnature > 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 deterministi= c > ECDSA for signing and we=E2=80=99re 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 trus= t > store on non-Android platforms. A command line tool to dump requests t= o > 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 interfa= ce. > - 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 show= s 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 bit= coinj > based app can be easily upgraded from SPV to full security just by run= ning > 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 tutor= ials > in other languages will come in future. > - The =E2=80=9CWorking with the wallet > =E2=80=9D 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=E2=80=99t need the user to install Ja= va. By > following this tutorial you will learn how to make a basic cross platf= orm > 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 =E2=80=9Cbitcoinj-core=E2=80=9D. You can auto-por= t 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. Coi= n 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 =E2=80=9Cnanocoins=E2= =80=9D to mean > satoshis (the old term predated the use of the word satoshi to describ= e 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=E2=80=99s have changed quite a bit: several > constructors were replaced with clearer static factory methods that ma= ke it > more obvious how their parameters are interpreted. The new methods don= =E2=80=99t > change their behaviour depending on the pattern of nulls passed into t= hem. > - Some unit testing utilities have been moved to the new testing > subpackage and cleaned up/rearranged. It should be easier to write uni= t > 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=3D154622311&iu=3D/4140/ostg= .clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a11c3e92089601d0504932e3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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" &= lt;mike@plan99.net> wrote:
I=E2=80=99m pleased to announce version 0.12 of bitcoinj, one of = the worlds most popular Bitcoin libraries. It is used by at least four Andr= oid wallets, three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp, Lighthouse,= BlueMatt=E2=80=99s relay network, bitpos, countless alt coin wallets, for = academic research projects and much more.

This release r= epresents 8 months of work. The biggest new feature is=C2=A0HD wallets. Oth= er notable enhancements include a bundled Tor client that can be activated = with one line of code, support for multisig wallets, much faster and determ= inistic ECDSA, many API improvements and big upgrades to the included GUI w= allet which can be seen in=C2=A0a new screencasted tutorial.
=
The commit hash of bitcoinj 0.12 is=C2=A083a9a71f3fff3f223d0= 737ad758b519a39dbbd62.=C2=A0

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 olde= st non-rotating key as the seed bytes, so old backups remain valid.
      • Thanks to devrandom, we have a= n integrated Tor mode using the Orchid library. The user does not have to i= nstall the Tor client as it=E2=80=99s all pure Java. WalletAppKit users can= enable usage of Tor with a single line of code. This support should be con= sidered experimental for now.
  • Thanks to Kosta Korenkov, we have an experimental multisig= wallets implementation. Multisig (also =E2=80=9Cmarried=E2=80=9D) 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 th= em in sync and starts vending P2SH addresses.
    • As part of this work, transaction signing is now pluggable. Tra= nsactionSigner implementations can be added to the wallet and will be seria= lized into and out of the users saved wallet file. Signers are given a tran= saction to sign in sequence. This is intended for risk analysis providers t= o provide a class that talks to their server to get a signature of the righ= t form, so that all bitcoinj based wallets can be easily upgraded to suppor= t the new provider.
  • Reject messages are now deserialized and logged, though not yet expo= sed in the API.
  • Upgrade= d 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 signin= g and we=E2=80=99re now using an accelerated secp256k1 implementation that = exploits the special properties of this curve, for dramatically faster calc= ulations.
  • Payment proto= col code improvements: Some X.509 utility code was refactored out of Paymen= tSession for general usage. StartCom was added to the default trust store w= hich was promoted to override the system trust store on non-Android platfor= ms. A command line tool to dump requests to stdout was added.
  • Thanks to Andreas Schildbach:
    • We are now BIP62 (canonical push encodin= gs) compliant.
    • A new Co= in class replaces usage of BigInteger for marking values that are quantitie= s of bitcoin. Formatting has moved into the new MonetaryFormat class.
      • <= li style=3D"padding:5px 0px;line-height:1.5em">The wallet now saves the fee= paid on transactions we calculated ourselves. This is useful for putting i= t 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.t= ext framework.
  • Added ne= w DNS seed from Addy Yeow.
  • Wallets can now have string->byte[] mappings attached to them, for l= ighter weight extensions.
  • Thanks to Richard Green, there is now a Python version of the Forwarding= Service program from the getting started tutorial. This shows how to use bi= tcoinj 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 securi= ty 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 hig= h level API for creating apps that have a Bitcoin wallet:
    • Now supports mnemonic code and restore from seed wo= rds. A date picker is provided to cut down on the amount of chain that need= s to be rescanned.
    • Supp= ort for encrypting wallets. Password is requested when needed. The difficul= ty of the scrypt function is selected to always take a fixed number of seco= nds even if hardware gets more powerful.
    • Some new animation and utility code backported from Light= house.
    • Tor support
      • =
  • Thanks to Martin = Zachrison, the micropayment channels implementation has received various im= provements.
  • Thanks to E= ric 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 obje= cts 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 a= nd small new APIs.

Documentation and tutorials

  • A=C2=A0JavaScript tutorial=C2=A0has been added, showing how to use= bitcoinj from this language. More tutorials in other languages will come i= n future.
  • The =E2=80=9C= Working with the wallet=E2=80=9D document has been significantly = extended to cover encryption, watching wallets, HD wallets and multisig/mar= ried wallets.
  • A=C2=A0ne= w document and accompanying screencast=C2=A0shows how to extend the Wal= letTemplate app to have a transactions list, and then make a native/bundled= packages that don=E2=80=99t need the user to install Java. By following th= is tutorial you will learn how to make a basic cross platform desktop walle= t of your own.
  • All othe= r docs were refreshed to the latest APIs.

API change= s

  • The package name has changed to org.bitcoinj and the core Maven a= rtifact name is now =E2=80=9Cbitcoinj-core=E2=80=9D. You can auto-port most= of your code by running=C2=A0find . -name '*.java' \| xargs sed -i .bak 's/com.g= oogle.bitcoin./import org.bitcoinj./g
  • Wallet.completeTx now throws more precise unchecked e= xceptions in edge cases, instead of IllegalArgumentException.
  • The use of BigInteger to represent q= uantities of Bitcoin has been replaced with the more efficient, type safe a= nd useful class Coin. Coin is mostly source compatible with BigInteger so y= ou can probably just do a search and replace to update your codebase. Utils= .bitcoinValueToFriendlyString and friends moved to CoinFormat.
  • NetworkParameters.getProofOfWorkLim= it was renamed to getMaxTarget for consistency with other Bitcoin codebases= .
  • The library no longer= uses the misleading term =E2=80=9Cnanocoins=E2=80=9D to mean satoshis (the= old term predated the use of the word satoshi to describe the smallest pos= sible amount of bitcoin).
  • TransactionConfidence no longer tracks total work done.
  • Because outputs are now shuffled any co= de during that assumes the ordering is preserved will break. You can set th= e shuffleOutputs field of SendRequest to false to disable this behaviour if= you need to.
  • The ECKey= and HD API=E2=80=99s have changed quite a bit: several constructors were r= eplaced with clearer static factory methods that make it more obvious how t= heir parameters are interpreted. The new methods don=E2=80=99t change their= behaviour depending on the pattern of nulls passed into them.
  • Some unit testing utilities have be= en 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 n= ow. 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.
    • <= /ul>


----------------------------------------= --------------------------------------
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/gam= pad/clk?id=3D154622311&iu=3D/4140/ostg.clktrk
__________________= _____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11c3e92089601d0504932e3f--