Re: [Bitcoin-development] bitcoinj 0.12

[Mike Hearn]

Hey Kristov,

> 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?
>
Stealth addresses and SPV don't mix well, so no. I wrote up a description
of how to do something similar with the payment protocol here:

https://medium.com/@octskyward/ecdh-in-the-payment-protocol-cb2f81962c1b

Because you can send data around outside the block chain on private
channels, with the pp the same issues don't crop up.

At the moment there are no concrete plans what goes into the next release.
I will be focusing on fully launching Lighthouse and crowdfunding for
decentralisation/crypto related projects, so I won't be doing any major
feature work on bitcoinj. Luckily it's become quite an active project now
and there are lots of contributors, so things won't stand still.

If I were to tackle a big project the next one would not be privacy
related. It'd be refactoring the wallet so it doesn't store transactions
directly anymore, just unspent outputs. Bitcoinj has always been largely
driven by the needs of Andreas' mobile app, and right now the top user
reported problem there is people hitting the scalability limits of the
current design (e.g. they are mining directly into their phone's wallet).
--
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

Re: [Bitcoin-development] bitcoinj 0.12

[Kristov Atlas]

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 

Re: [Bitcoin-development] bitcoinj 0.12

[Tom Harding]

I'm stunned by what bitcoinj can do these days.  Just reading the 
release notes gives one app ideas.  Mike, Awesome.



On 10/3/2014 5:49 AM, Mike Hearn wrote:
I'm pleased to announce version 0.12 of bitcoinj, one of the worlds 
most popular Bitcoin libraries.


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

Re: [Bitcoin-development] bitcoinj 0.12

[Pavol Rusnak]

On 10/03/2014 02:49 PM, Mike Hearn wrote:
> I’m pleased to announce version 0.12 of bitcoinj
> 
> This release represents 8 months of work. The biggest new feature is HD 
> wallets.

Congratulations on this release and I am quite happy that bitcoinj now
fully supports BIP32 and BIP39!

Does it also support various HD wallet structures such as BIP44 for example?

-- 
Best Regards / S pozdravom,

Pavol Rusnak 

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

Re: [Bitcoin-development] bitcoinj 0.12

[Wladimir]

On Fri, Oct 3, 2014 at 2:49 PM, 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.

Congrats on the release!

Wladimir

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

[Bitcoin-development] bitcoinj 0.12

[Mike Hearn]

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 ba