Allows mnemonic code backup and restore using bitcoinj's seed

[shkschneider]

Password encrypted list of keys to a file is a good backup solution. Yet I believe this app lacks a way to import to other wallets (easy solution is to move all coins of course). I couldn't get a WIF private key out of bitcoinj but the mnemonic seed was not a problem. This commit exposes new backup and restore options.

[shkschneider]

Related to https://github.com/bitcoin-wallet/bitcoin-wallet/issues/245

[schildbach]

While this is a very straightforward way to implement a mnemonic backup, it has a couple of problems:

1. Restore always needs to sync the blockchain from 2014 on, rather than just the birthdate of the own wallet, with the number of blocks to sync getting more and more each day. BIP39 is missing a birthdate.
2. There is missing an information about what type of addresses are in the wallet. Currently the app only supports P2PKH, but segwit is coming soon and we will have multiple types of addresses in parallel. BIP39 is missing a version field or similar.
3. Wallet files can have multiple KeyChainGroups, each with independant seeds. Your solution only backs up the "active" KeyChainGroup. While only the active (most recent) should be the one having Bitcoins on it, sometimes old ones can still be valuable, such as if wallet maintenance wasn't successful (after a key compromise) or if someone simply sends coins to any old (compromised) addresses.
4. Same as 2, but for old non-HD addresses.
5. Wallet metadata (labels, payment requests, …) isn't backed up. Granted, they are currently not properly restored anyway but they could, with some effort.

My plan is to address this with the following wallet backup flow:

1. User enters their spending PIN, if the wallet is encrypted.
2. Seed is displayed, together with the appropriate warning to write this down at a secure place. Probably it will be an extension to BIP39, such as adding two words to include wallet birthdate and version field.
3. The seed is used as a password for backup encrypting, so the user won't be able to pick their own backup password any more. (TBD: In the backup, any spending PIN gets removed.)
4. The backup is put on cloud storage via the Android storage access framework. No detour via external (in real: internal) storage like it is today. Users tend to loose their external storage together with their phone anyway, so it's just a false sense of safety.

To restore, users either tap their backup file in the cloud storage app to restore from file, then enter their backup password. Or, they use an app-internal method to restore from their backup password (=seed) in case they lost the backup file.

[shkschneider]

Some flaws are from BIP39 I see. I read you comments and might work on something more elaborate, yet even if BIP39 is not precise enough, it is widely used and works in most cases as-is, so I won't derivate too much.

The main problem then is the mnemonic code only format that does not provide enough information to fully restore a wallet. It's fine to me, there are other backup methods, this method has its advantages and drawbacks, but that's BIP39.

To me, birthdate is not a problem. Format and metadata are not defined by BIP39 and I'm totally ok with this method not backing up those. BIP39 restores the private key, giving you control over your coins and that's it. You pointed out a possible problem with KeyChainGroup and I agree, I'll digg into it. You also wanted more encryption and I agree a passphrase could be put in place.

I still think this basic BIP39 implementation is better than having only the file dump. But for sure this app would need better backup/restore solutions. I'll do what I can. Thanks you reviewing my modest contribution.

[shkschneider]

By the way, please tell me if there is a way, using bitcoinj, to get a master private key? I couldn't find it.

[schildbach]

BIP39: Yes, I would not stray too much from the standard either. My idea is just to add two words from the same wordlist containing birthdate, a version and a checksum for those two fields. Then again, if @prusnak comes up with a new standard as he revealed today, we may also wait for that.

However, even straight BIP39 will not make seeds really compatible. Most other wallets are using the derivation path from BIP44, while bitcoinj-based wallets use the BIP32 "default account". So maybe it's actually a feature to have BIP39-incompatible seeds?

[shkschneider]

Allright then. We should have mnemonic words and could add version and checksum to them, as defined by this app. The first 12 words will still be compatible with other BIP39 tools. Fine to me. I'll play around anyway, and see if @prusnak will come up with something well defined.

[HostFat]

Any news about this?

[C7655]

How to add a few more things to do in Bitcoin account information

[JeffreyLeonard]

Can the code backup the wallet?