Bitcoin Wallet 4.0 alpha 1

[Andreas Schildbach]

I'm proud to present the first alpha version of what will become Bitcoin
Wallet 4.0.

Without further ado, here are the user-facing changes:

- All Bitcoin addresses are now deterministically derived from one
single secret, which was created when you installed the app for the
first time. So from now on, only one backup is needed to recover all
your future funds in that wallet. However, metadata such as fee
information (see below) will be lost if you don't refresh your backup.
- The app does its best to not reuse addresses any more. Request coins
will use a fresh address on each invocation. The current address in the
QR code on the main page changes as soon as coins are received on it. If
you want to still use fixed addresses, you can do so in Your addresses.
- When sending coins, the fee is calculated and shown before you press
Send. After sending, you'll see the paid fee in the transaction list.
- When sending coins, most errors are now shown already before you press
Send.
- Labs feature: Instead of showing the "from address" of received
transactions, show the address you received the coins on. You need to
enable this in the settings.
- The app now requires Android 4.0.3. This makes UI development much
easier in future.
- The app has a fresher, sharper looking app icon. The icon for the
testnet version is now entirely grey.


Caveats:

- The version string is still at "3.56-bitcoinj0.12". This will be fixed
at release, when I assign the final version.
- Bitcoinj will likely change its deterministric structure in the coming
weeks. This means that all coins you receive from now until then will go
missing. This also affects change from your own payments! The missing
coins are *not* lost and can recovered with some effort. So if you're
using this on mainnet, please know exactly what you're doing!
- On first app start, derived keys need to be pre-calculated. On fresh
installs, unfortunately this happens while the app is loading -- it
causes a white screen for 5-10 seconds.
- One fixed address is still created for you in Your addresses. I will
probably remove this for final release to discourage the use of fixed
addresses.
- No export/import of wallet seed yet (BIP39).


Testnet Binary:
http://wallet.schildbach.de/bitcoin-wallet-3.56-bitcoinj0.12-test.apk

Testnet Source:
https://github.com/schildbach/bitcoin-wallet/tree/bitcoinj-0.12

Mainnet Source:
https://github.com/schildbach/bitcoin-wallet/tree/bitcoinj-0.12-prod


I'd be happy if you give it a go and report any issues either here, or
in the GitHub bug tracker (please make clear you're testing this alpha).

Thanks to all the contributors (especially those to bitcoinj 0.12) for
making this possible! HD wallets is a giant leap for Bitcoin!

[Mike Hearn]

Nice! I didn't see any issues yet, although the 5-10 seconds of white screen is not great. I thought we had been able to fix that by making the key derivation take place on a network thread. Why is the screen white?

For now I'm just using the testnet version. I'm becoming less convinced we should switch to a BIP43 type hierarchy for 0.12. Or at least it should be optiona.

--
You received this message because you are subscribed to the Google Groups "bitcoinj" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andreas Schildbach]

On 08/23/2014 12:50 PM, Mike Hearn wrote:

> Nice! I didn't see any issues yet, although the 5-10 seconds of white
> screen is not great.

Did you see it? In your case if you were upgrading, it should have
derived the keys "as part of the upgrade".

> I thought we had been able to fix that by making
> the key derivation take place on a network thread. Why is the screen white?

What happens is this:
- There is no way to run any app code after a fresh install until you
start the app manually. (At least officially, I know there are tricks
but I'd rather not exploit them.) So there is no chance to run key
derivation "as part of the app install", similar to how keys are derived
"as part of the upgrade".
- When you start the app manually, the activity starts the service,
which starts the PeerGroup. Their threads initialize quite quickly and
lock the wallet in order to derive 200+ keys.
- At that point the UI is blocked for some seconds, more or less. Some
UI components use loaders and can deal with high execution latency
pretty well. Some not so. When I said "screen white" I meant the UI did
not even have a chance to inflate completely. Only the action bar was
visible.

I've now delayed the start of the service by 1 second, so that the UI
has got enough time to inflate. I think that workaround is good enough
for 4.0.

If we want to improve I think bitcoinj 0.13+ should not hold the wallet
lock while (mass-)deriving keys. But for 0.12 I think it's ok.

> For now I'm just using the testnet version. I'm becoming less convinced
> we should switch to a BIP43 type hierarchy for 0.12. Or at least it
> should be optiona.

I'm also undecided.

The positive: Our current "BIP32-hierarchy default account" structure is
actually BIP43 conform. All it would need is to declare "BIP43 usage 0"
is assigned to "BIP32-hierarchy default account". Here is my PR for the
BIP: https://github.com/bitcoin/bips/pull/94

The negative: "BIP32-hierarchy default account" seems to be used by
almost no one. And there is no chance to effectively expire keys ever.
I'm sure storing key expiration dates in wallet metadata is not a robust
solution. It needs to be derived from the seed (+ blockchain state)
somehow, see my mailing list posts "bitcoinj 0.12 deterministic
hierarchy" for more on that discussion.

It would help if we would at least have a consensus of where we'd like
to be. Then we can decide if we can make it for 0.12 or for a later release.

> <mailto:bitcoinj%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "bitcoinj" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoinj+u...@googlegroups.com

> <mailto:bitcoinj+u...@googlegroups.com>.

[Mike Hearn]

Did you see it? In your case if you were upgrading, it should have
derived the keys "as part of the upgrade".

I did not see it. But I don't remember if I had the testnet wallet installed before or not.

 

- When you start the app manually, the activity starts the service,
which starts the PeerGroup. Their threads initialize quite quickly and
lock the wallet in order to derive 200+ keys.

Yes. So the right fix is to make the service start the PeerGroup only after the UI is on screen and doesn't need the wallet immediately for a while.

 

I've now delayed the start of the service by 1 second, so that the UI
has got enough time to inflate. I think that workaround is good enough
for 4.0.

Yeah, that works too, though it'd be better if the service just waited for an explicit "i'm ready" signal. A fixed delay is kind of a hack.

 

The negative: "BIP32-hierarchy default account" seems to be used by

almost no one.

I think it's used by a few different wallets at least. GreenAddress, Wallet32, maybe BitGo. I forgot.

 

And there is no chance to effectively expire keys ever.
I'm sure storing key expiration dates in wallet metadata is not a robust
solution. It needs to be derived from the seed (+ blockchain state)
somehow, see my mailing list posts "bitcoinj 0.12 deterministic
hierarchy" for more on that discussion.

Yes, but we do want to delay 0.12 even further to find some solution to that? We should be able to fit a LOT of keys in RAM.

[Andreas Schildbach]

On 08/23/2014 03:25 PM, Mike Hearn wrote:

> The negative: "BIP32-hierarchy default account" seems to be used by
> almost no one.
>
>
> I think it's used by a few different wallets at least. GreenAddress,
> Wallet32, maybe BitGo. I forgot.

This compatibility issue is already becoming confusing. And we only have
2 standards right now (-:

Wallet32: A guy named "Perlover" states in
https://github.com/bitcoin/bips/pull/95 that Wallet32 is BIP44.

> And there is no chance to effectively expire keys ever.
> I'm sure storing key expiration dates in wallet metadata is not a robust
> solution. It needs to be derived from the seed (+ blockchain state)
> somehow, see my mailing list posts "bitcoinj 0.12 deterministic
> hierarchy" for more on that discussion.
>
>
> Yes, but we do want to delay 0.12 even further to find some solution to
> that? We should be able to fit a LOT of keys in RAM.

I fully agree. I'm just afraid of a migration process later. I *hate*
carrying around all these backwards compatibilities. Makes me wonder if
Bitcoin Wallet can still deserialize these Java-serialized wallets… (-:

Given this question is the only issue left and based on the fact that
we're de-facto BIP43 conformant, I would propose to go forward and start
the stabilization phase for 0.12. What do you think?

[Mike Hearn]

I think Wallet32 is BIP44 compliant only if you ignore the fact that the spec has many requirements, like auto scanning for new accounts. But maybe I'm wrong. It uses a different HDW implementation to bitcoinj even though it's based on bitcoinj.

 

Given this question is the only issue left and based on the fact that
we're de-facto BIP43 conformant, I would propose to go forward and start
the stabilization phase for 0.12. What do you think?

I still want to spend a bit of time doing the auto scan restart if we exhaust the lookahead zone. Probably in early September.

[Ken Sedgwick]

Wallet32 implements BIP-0044.

Ken

--

You received this message because you are subscribed to the Google Groups "bitcoinj" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Ken Sedgwick
Bonsai Software, Inc.
http://www.bonsai.com/ken/
(510) 269-7334
k...@bonsai.com
Public Key: http://www.bonsai.com/ken/ken.asc
GPG Fingerprint: 851E 3B07 E586 0843 9434  5CC7 4033 3B9B 3F3F 9640

[Mike Hearn]

Have you implemented the auto discovery of new accounts, like stopping chain sync/resetting the filter/restarting it? I guess that'd involve quite some changes which I will have to reimplement, so would be nice if the patches can be upstreamed :)

[Ken Sedgwick]

I don't current auto-discover new accounts:

1. On recovery I ask the user how many accounts to recover.

2. With "paired" devices, a rescan is neccessary after adding accounts that exist on the other wallet.

Ken

[Mike Hearn]

OK, that's what I thought. Technically BIP44 requires auto discovery according to my reading, but from a users perspective I think nobody will complain if you claim to be myTREZOR compatible and the app works that way. As long as they can get to their money I suspect it'd be fine. Of course if they want to sync their wallet between myTREZOR and Android and then they add an account it won't work, but I doubt anyone will because that'd require sharing the seed ... sort of defeats the point of the TREZOR if you do that.

[Mike Hearn]

It started crashing for me too now with the error you reported last night:

I guess it will not be usable until fixed.

W/CrashReporter(28487): java.lang.RuntimeException: Unable to create application de.schildbach.wallet.WalletApplication: com.google.bitcoin.core.ECKey$MissingPrivateKeyException

W/CrashReporter(28487): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4331) ~[na:0.0]

W/CrashReporter(28487): at android.app.ActivityThread.access$1500(ActivityThread.java:135) ~[na:0.0]

W/CrashReporter(28487): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1256) ~[na:0.0]

W/CrashReporter(28487): at android.os.Handler.dispatchMessage(Handler.java:102) ~[na:0.0]

W/CrashReporter(28487): at android.os.Looper.loop(Looper.java:136) ~[na:0.0]

W/CrashReporter(28487): at android.app.ActivityThread.main(ActivityThread.java:5001) ~[na:0.0]

W/CrashReporter(28487): at java.lang.reflect.Method.invoke(Native Method) ~[na:0.0]

W/CrashReporter(28487): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785) ~[na:0.0]

W/CrashReporter(28487): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601) ~[na:0.0]

W/CrashReporter(28487): Caused by: com.google.bitcoin.core.ECKey$MissingPrivateKeyException: null

W/CrashReporter(28487): at com.google.bitcoin.core.ECKey.getPrivKey(ECKey.java:433) ~[na:0.0]

W/CrashReporter(28487): at com.google.bitcoin.core.ECKey.getPrivKeyBytes(ECKey.java:898) ~[na:0.0]

W/CrashReporter(28487): at de.schildbach.wallet.WalletApplication.loadWalletFromProtobuf(WalletApplication.java:311) ~[na:0.0]

W/CrashReporter(28487): at de.schildbach.wallet.WalletApplication.onCreate(WalletApplication.java:132) ~[na:0.0]

W/CrashReporter(28487): at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1007) ~[na:0.0]

W/CrashReporter(28487): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4328) ~[na:0.0]

W/CrashReporter(28487): ... 8 common frames omitted

[Andreas Schildbach]

Indeed. I uploaded a new version to the same URL which doesn't
auto-derive an "imported" key and also doesn't have the "Add" button any
more.

After you upgraded to that version you need to clear your app data to
get rid of the read-only key.

> --
> You received this message because you are subscribed to the Google
> Groups "bitcoinj" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoinj+u...@googlegroups.com

> <mailto:bitcoinj+u...@googlegroups.com>.

[Andreas Schildbach]

I updated the alpha, let's call it alpha 2. Here is the news:

- I'm very confident that we will go with the BIP32 default account
hierarchy. Thus, this time I have also built a mainnet version. Use it
with care! (Backups, backups, …)
- On Android 4.1+, the app-widget is now horizontally resizable.
- On fresh installs, there will be no more fixed addresses. Also, no
more fixed addresses can be added. At some point after 4.0, the fixed
address list will go away.
- It contains fixes for the issues you reported. Thanks for helping!

Testnet Binary:
http://wallet.schildbach.de/bitcoin-wallet-3.57-bitcoinj0.12-test.apk

Mainnet Binary:
http://wallet.schildbach.de/bitcoin-wallet-3.57-bitcoinj0.12.apk

[Mike Hearn]

Seems to be working for me.

--
You received this message because you are subscribed to the Google Groups "bitcoinj" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+u...@googlegroups.com.

[Gary Rowe]

Hi Andreas,

Congratulations on the second alpha :-)

When you say you're supporting the BIP32 default account model, does that mean that you won't be supporting BIP44 and consequently the possibility of a Trezor on Android in the future?

Cheers,

Gary

[Andreas Schildbach]

Hi Gary,

thanks. Afaik Trezor is hierarchy agnostic and thus there is nothing
stopping Bitcoin Wallet to support Trezor in a future version.

As for BIP44, nobody implemented it in bitcoinj despite several calls
for agreeing on a hierarchy. I also think its rather difficult given the
fact that BIP44 mandates accounts where bitcoinj doesn't support that.
So I'm afraid the answer is no, 4.0 won't support BIP44.

Cheers,

Andreas

On 09/03/2014 12:12 PM, Gary Rowe wrote:
> Hi Andreas,
>
> Congratulations on the second alpha :-)
>
> When you say you're supporting the BIP32 default account model, does
> that mean that you won't be supporting BIP44 and consequently the
> possibility of a Trezor on Android in the future?
>
> Cheers,
>
> Gary
>
>
> On 3 September 2014 10:47, Mike Hearn <mi...@plan99.net

> <mailto:bitcoinj%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "bitcoinj" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to bitcoinj+u...@googlegroups.com

> <mailto:bitcoinj+u...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "bitcoinj" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoinj+u...@googlegroups.com

> <mailto:bitcoinj+u...@googlegroups.com>.

[Andreas Schildbach]

I updated the links with alpha 3. There have not been many changes:

- App-widgets of mainnet and testnet versions are distinguishable even
without the app icon.
- Latest bitcoinj master.

Still I encourage everyone who has alpha 1 or 2 installed to upgrade to
alpha 3. Also, you should not go back to the version on Google Play or
parts of your funds will go missing (at least temporarly).

Testnet Binary:
http://wallet.schildbach.de/bitcoin-wallet-3.58-bitcoinj0.12-test.apk

Mainnet Binary:
http://wallet.schildbach.de/bitcoin-wallet-3.58-bitcoinj0.12.apk

[Mike Hearn]

Still I encourage everyone who has alpha 1 or 2 installed to upgrade to
alpha 3. Also, you should not go back to the version on Google Play or
parts of your funds will go missing (at least temporarly).

This means disable auto updates. I got auto updated this morning and my wallet was deemed "corrupted" (version too new), replayed and my balance went to zero. Re-upgrading fixed things because of the deterministic HD upgrade.

It'd be nice if the Store version refused to start if it discovered it had been downgraded across wallet versions and displayed a useful activity. 

[Andreas Schildbach]

Again, I updated the links with alpha 4. Changes since alpha 3:

- Resolve issue with restoring backups that have been renamed.
- Latest bitcoinj master.

I encourage all alpha testers to upgrade to alpha 4. Also, you should

not go back to the version on Google Play or parts of your funds will go

missing (at least temporarly). Please disable auto updates for as long
as you're an alpha tester.

Testnet Binary:
http://wallet.schildbach.de/bitcoin-wallet-3.59-bitcoinj0.12-test.apk

Mainnet Binary:
http://wallet.schildbach.de/bitcoin-wallet-3.59-bitcoinj0.12.apk


I must say so far, I'm pretty happy about the new version 4.0 and
bitcoinj 0.12. Although HD changes a lot of things internally, I have
not encountered or got reported a single critical issue. Even the corner
case of accidently downgrading to non-HD (which will not happen once
released) did not cause permanent loss of money.

I'm now also confident that HD will not degrade performance
significantly. For "normal" use of wallets, it will be pretty quick.
There are still issues with wallets being used excessively for
mining/gambling/microjob payouts, but those were present in 3.x as well.
We will need to tackle them after going to HD.

From my point of view, the remaining TODOs are:

- Get bitcoinj 0.12 released.
- Migrate to android-maven-plugin 4.0 and change the project directory
layout to then unified Maven/Gradle structure.

Planned for after 4.0:

- Spending PIN/password.
- Backup to and restore from BIP39 seed. Compatibility to (selected)
other wallets.

[Andreas Schildbach]

I put up the release candidate for Bitcoin Wallet 4.0!

https://plus.google.com/101256420499771441772/posts/VhyWchXkBFR

[Andreas Schildbach]

Sorry that was the wrong link for the announcement. The correct one is:

https://plus.google.com/101256420499771441772/posts/KujxxG844gH