Open mackuba opened 11 years ago
How much time would be required to switch the main user address generator to use a BIP32-compatible seed with no other interface changes? By eventually supporting import via seed phrase, it be easy for users to switch wallets while retaining their balances.
Relates to #98
@nschum Could you take a look at what method generates the seed and estimate how much work would be required to switch to BIP32-compatible generation?
My current project is working on making bitcoinj use deterministic wallets by default (probably not for 0.11 which is nearly done, but as a high priority for the release afterwards). I plan to do silent/automatic upgrades of old wallets too, so you should be able to just shelve this for now and eventually you will get this "for free".
How would supporting old wallets work - will there be two sets of keys in one Wallet
, some generated from an HD seed and some created the old way? (In Hive we'd prefer to avoid such situation because we have no UI to handle multiple keys, so we're thinking that we'll have to ask users to transfer the money from the old address to the new one during the migration.)
Yes, exactly. You don't have to expose multiple keys in the UI if you don't want to, just whichever one is "active". But behind the scenes addresses will need to start changing for privacy reasons. It can look much like bitcoin 0.1 did, with a single "Your current address" type field that changes every so often.
Status update: Mike's working on this, but it's not finished yet, so probably off the table for February. I wouldn't want to replace such a critical part of the app with something unstable, that would be asking for trouble...
There's now a hdw-alpha branch that would let you prototype this. HD wallets in bitcoinj are not yet finished, but there should be enough there for you to start and work in parallel to me. Paper wallets (write down the 12 words) are supported.
Nice! At the moment I'm busy with the Payment Protocol though, HD will have to wait anyway.
Since hive-js is about to launch with BIP32 support, we should maybe get this moving.
Too many things to do, too little time... :)
I want to get a few smaller things done first, e.g. transaction info, clearing app data or exporting private keys. BIP32 will be a big task. (Also, I don't know if @mikehearn has finished the implementation in bitcoinj?)
Actually I'm hoping the upgrade would be very simple for wallet authors. I did a lot of work in bitcoinj to make it easy. The code in git master has an HD wallet but it's not finished yet. You can see the todo list here:
https://github.com/bitcoinj/bitcoinj/blob/master/HD%20Wallets%20TODO.txt
The most important thing is the automatic upgrade from old wallets, of course. Also we need to figure out/fix/improve the current vs fresh address API. Once that's done a limited beta/preview of HDW should be possible though wallet compatibility might be broken before release.
TODO:
@mikehearn @weilu can you think of anything else we'd need to change?
Also, at what moments does the current address change to a new one?
Something potentially to be added in the future: option to have several "accounts" within a wallet, so that you can keep your money grouped in different buckets. Does bitcoinj even support something like this now?
Yay!
bitcoinj does not support any notion of an account, though you can add multiple wallets (however if you remove them again, they will miss out on parts of the chain and won't automatically rewind and catch up when readded). However I think the most common use case for an account is to keep different aspects of one's financial life separated, in which case just having a single wallet with a list of sub-balances is probably sufficient.
Yes you sign messages with leaf keys.
The current key changes to a new one when money is received on it. There's currently no way to force it to change, though that'd be easy to add if desired. In the "receive money" window of most wallets a fresh address is used so it can be labelled. The "current address" is used for more passive stuff like an always-present QR code. You might decide you don't want the concept of a current address at all, and make the user always click "receive money".
Hive web only supports the default accounts: m/0'/0 for external (receiving) addresses and m/0'/1 for internal (change) addresses.
The PIN required by Hive web requires the client to talk to our server to exchange for a long token which is then used to decrypted the locally encrypted seed. I'm not sure what's the best approach for osx client here: PIN integration will add the server as a dependency, which sucks. Alternatively we can forget about PIN for osx because after all it was designed for convenient mobile access. Instead, we can keep using the password that osx currently asks the user to set. But unfortunately we cannot use the password as the salt for PBKDF2 as specified in BIP39 because 1) hive web uses the default empty string as the salt 2) user will not be able to change the password. In both cases the same mnemonic will yield a different seed.
bitcoinj doesn't use the salt field in BIP39 either. The password is used to encrypt the seed. You cannot show your seed words without the password as a result. Please see the code I checked into wallet-template for an example of how to integrate encryption, BIP32 and BIP39 together. Also, that code shows how to make password derivation as strong as possible.
I quite like recommending Hive for Mac OS users but the lack of privacy with address reuse makes me cringe whenever I do
Sorry, that's not going to happen... Hive is no longer being maintained at this point, I'll only release a small update with some kind of announcement.
https://en.bitcoin.it/wiki/BIP_0032
Generating master key: https://en.bitcoin.it/wiki/BIP_0032#Master_key_generation
Some C++ lib: https://github.com/CodeShark/CoinClasses/tree/master/tests/hdwallets