Topic: Going forward: MultiBit HD and MultiBit Classic - page 2. (Read 11174 times)

Security, passwords, private keys and wallet recovery are all related.

Here is a rough draft of what we are thinking of doing (it might be refined as we go but you'll get the overall picture):



MultiBit HD Password Strategy

Introduction
This document describes the overall strategy for password management in MultiBit HD.
Primary goals are that:

1) Data is stored securely, locally.
2) If the user loses their password, there is a way they can recover it.
3) If the user loses their computer, they can recover their wallet from a cloud backup.



Description of Seeds and Passwords.
As the wallet used in MultiBit HD is a hierarchical deterministic wallet it has a seed from which all the Bitcoin addresses can be calculated. (BIP 32)

This seed can be transformed to a mnemonic phrase, typically 12 words long. (BIP 39). At wallet creation the user is strongly advised to write this mnemonic phrase down on a piece of paper and keep it safe.

The seed is the master private key which can be used to sign spends. It can also be used to create a master public key which can be used to generate addresses but cannot sign spends.

The master private key needs to be stored locally, securely and so needs to be encrypted. A wallet password (similar to the existing MultiBit Classic) is used to encrypt this. The user chooses this password in a similar way to the existing MultiBit Classic.

The wallet password is used to encrypt:
1) The master private key and any derived private keys. These are decrypted as required on spends.
2) The user's transaction details. These are decrypted at MultiBit HD start up.
3) The user's contact details. These are decrypted at MultiBit HD start up.


Wallet Password recovery
Users are used to the idea of being able to recover a forgotten password. To enable this an encrypted copy of the wallet password is stored locally. This is encrypted with a PGP public key that is derived from the master private key. This means that as long as you have the mnemonic phrase you can recover the wallet password.

The process is as follows:

1) The master private key is used to generate a PGP private key and PGP public key.
2) The PGP public key is used to encrypt the wallet password. This is stored locally. The PGP private key is discarded. (It can be regenerated given the master private key).

When the user needs to recover their wallet password they do the following:

1) User enters the mnemonic phrase.
2) The mnemonic phrase is used to regenerate the master private key.
3) The master private key is used to generate the PGP private key.
4) The PGP private key is used to decrypt the locally stored encrypted wallet password.
5) The recovered wallet password is shown to the user. They can then use this to decrypt their wallet and use it.

Wallet cloud backup
A wallet that is both encrypted and backed up to the cloud enables the user to recover their wallet if their computer is lost or stolen.

This will be implemented as follows:
1) The mnemonic phrase is used to generate the master private key.
2) The master private key is used to generate a PGP private key and a PGP public key.
3) The PGP public key is stored locally. The PGP private key is discarded (It can be regenerated from the mnemonic phrase).
4) Wallet backups are stored locally (in a similar way to the existing Multibit Classic). These are encrypted with the PGP public key.
5) The user can also choose to store backups in their “cloud backup” directory e.g. SpiderOak sync directory. These wallets are encrypted with the PGP public key.


If the user needs to reuse a wallet backup they offer it up to MultiBit HD, which will then prompt for the mnemonic phrase. This will enable the PGP private key to be recreated and the wallet decrypted.

So if some thing happen with wallet file when you reinstal for example Windows and like to recover your account you can't do noting without your private keys - private key are basic of Bitcoin technology and now i know i never use MBHD and i thing you try to discover hot water.
There are one solution to be function export private key to the file for safety reason and recover account in another client but no function import if  in MBHD is impossyble to recover account from private key but you have to know HMBD will be the first client why can't do this.
And one more question how you generate new addresses and import addresses from another clients - you have to thing about this if you like your client to be more popular.

More requests:

1) When I want to send bitcoins, I would like to be able to specify which previous txout's I want to use. This is important for anonymity. It should work similar to the "custom send" in the blockchain.info wallet.

2) I don't know if it is already standardized in the HD proposal how the seed could be exported to a list of words. It would be nice to have the possibility to export the seed in a way which is easier to type in by hand. This would be very helpful if you want to use your offline wallet on PC's that don't have a scanner/printer/webcam. For security you might prefer to only generate random backup words from your seed address and don't allow the user to select his own words.

Hi filchef,

Thanks for your input.

For the console (or API, as they are similar) I've not put it into MultiBit and probably won't put it into MultiBit HD. I want MBHD to be as close to 'shrinkwrap' as possible as it is for the general user rather than the advanced user.

Of course there is nothing to stop people using bitcoinj in command line - Mike Hearn has written a CLI.
A CLI also opens up another whole attack vector (scripted attacks) which is another reason I don't want to put it in.


Test mode - yes there should be compatibility with the testnet (it's an oversight it's not really there in multibit rather than a design decision).


Because MBHD will ONLY support HD wallets importing pure keys won't be supported as it invalidates being able to backup and recreate addresses from a seed/ mnemonic phrase. I appreciate this probably won't be very popular with 'private-key-istas' who like to move private keys around. The reason for this is that messing up or losing private keys is the number one problem with MB at the moment. For MBHD to be used by general users they need more safety in managing private keys.


There are a few things that MBHD won't provide because they create LOTS of support calls and it's just not sustainable going forward if and when there are more users.

For instance, choosing where to put your wallet sounds an innocent feature but causes lots of support calls when people create a wallet and then cannot find it. For MBHD I am only going to put wallets in the user data directory to simplify things. Edit: the wallet file name will be derived from the master public key so users won't even choose the filename (there will still be a description field).

My wishes
 1.Console like BitCoin-Qt
 2.Test mode like BitCoin-Qt or test wallet
 3.Function for import and export private and public key - sometimes public key is need for mining in p2pools and private key is need for transfer account to another client.
 

Yeah -  I think at the moment having the addresses and send all together is a bit limiting/ complicated.
There is a little too much going on at once and it makes multi-send quite difficult.
(I think I will copy Bitcoin-QT actually)

Having a search for the address (like on the Schildbach Android wallet) would be very useful yes

I tried using BitcoinCharts for rates a while ago but, when I looked, it had lots of 'stale' rates (exchanges that were dead or had very few trades). You couldn't use them as they had old, misleading rates unfortunately.

I am working on a new very of MultiBit classic next week - it is mainly big fixes and the like but there will be bumps for both bitcoinj and xchange so there might be some new exchanges appearing (I only put exchanges in that are rock solid as it annoys users if they are up and then down and then up again)

The separate address book seems a nice idea.

It would be nice to separate transactions from the addresses as well: at the moment the process is kinda cumbersome because you can send money and edit the addresses at the same time (and by the way with 0.5.14, if you select an address from the address book on the bottom panel, delete the address from the textfield in the top panel and then click "new", the address gets wiped in the address book).

It would be very nice to be able to send BTC by either typing/pasting an address or by typing a label in the address field. In this case autocompletion with a drop down menu (think about how google works) could be a way to select quickly the address we need, after all it is a lot easier to remember labels.

About the tickers, I see that XChange allows access to Bitcoincharts: maybe you could fetch data for different exchanges, since the list of supported ones seems limited.

I know this is not the right thread to ask, however... any news on the next release of multibit "classic" ?

I think we are going to add a separate address book or 'Contacts' in MBHD as it will need more flexibility going forward.
I agree the Bitcoin-QT address book and multisend works pretty well.


Transaction display I agree with your comments - not sure if we are going to have a full grid of transactions displayed yet.


We use the XChange code for our tickers so will use what they have coded up. We would not want to add in "insert your ticker code here". It's too error prone. We want MBHD to be as close as we can manage to being bulletproof.


Currently MultiBit is being used by something like 80,000 or 100,000 users. They will be 9,000 downloads just today.
MBHD we want to be usable in 'the next push' of Bitcoin's expansion so we are thinking about what we need to do for 1,000,000 users. Inevitably this will entail a bit of simplification and hand holding.

Hi,

I would like to see the following features implemented in Multibit HD:

Transactions
- More columns:
   Split the description in Operation (sent/received) and Destination

- Add a drop down menu so that I can filter which transaction to show (Sent/Received/All)

Address book
- The possibility to discern my own remote destination addresses (think about exchanges or online wallets) from other destination addresses

- The possibility to hide receiving addresses I am not using anymore.

Overall the way Bitcoin QT managed transactions and the address book was nice.

Tickers
- More exchanges or the ability to add custom tickers, by specifying custom queries (interpreting REST/JSON/whatever comes back)
This could be achieved using external config files where youo could specify your query and how to map the results to specific variables "plotted" in the GUI

Hi nomailing,

That is an interesting idea to have a live CD with MultiBit HD on it.
I imagine for the next few months we will be busy doing the minimal-viable-product version of MBHD so any 'nice-to-have' things won't get any time spent on them unfortunately.

That being said, all the bitcoin clients are open source so anybody could provide a 'Bitcoin Uber Live CD' with all the clients on if they were keen. They would have to support updates to both clients and the OS which is where it becomes a bit more time consuming.
(Generally packaging is the least loved aspect of software development I find !)

Nice to hear about Multibit HD development.
I will definitely switch to it when it is ready.

I have a request, which I would really like to see:

Please provide it as a live-cd.iso, which you can just burn and use.
I think now with deterministic wallets it makes much more sense to really integrate it on a live cd, because you don't need to backup your wallet.

If you would package it with a nice linux distribution, it would be the ultimate solution for the users, because:
- you can trust the pc (no keyloggers)
- easy to install (just burn a cd)
- no external wallet backup necessary (perfect for live cd)

In contrast, if you just provide the executable as a download, it has several drawbacks:
- too much hassle for standard users to integrate it on their own live-cds (even most experts wouldn't do, you have to also install java etc.)
- false impression of security, because some computers have keyloggers etc
- with HD wallets more users will just use their wallet on insecure PCs!

I think this is even more important when the client supports HD wallets. Because with HD wallets you incetivise people to use the client on a lot of insecure computers.
With Multibit Classic this problem is not so dramatic, because most users will use it just on one single computer at home, where they have saved their wallet.dat.
So this would be the right time to think about the problem of trojans and keyloggers. Otherwise with the development of Multibit HD you might even increase the risks of users that their coins will be stolen.

*Edit: Therefore I think it would even make sense to add another client section on bitcoin.org which is called "bitcoin live-cds"

Fair point

Please don't nag us. If we choose to use Multibit Classic, it's because we want to and we chose to do so. Don't rub it in our face.

I was only talking about private keys, but now that you mention it this idea extends nicely to whole wallets too; it'll certainly be less complexity and more reliability than the P2P DHT you suggested elsewhere. Given that wallets can, and probably should, be implemented as append only data structures with external indexes(1) the append-only nature of data included in transactions comes naturally. Of course you leave out the transactions themselves, hopefully for obvious reasons, and what's left is just metadata like labels and some other stuff like micropayment channel refund transactions and private keys. Usually you can probably just include the latest new bit of data that got appended in your latest transaction, although in the case of refund txs it's probably worth it to artificially trigger an extra dummy one for the peace of mind. Either way the data can be stored in CHECKMULTISIG/unspendable outputs easily enough, and if you are feeling daring you could even implement ByteCoin's idea for storing 32 bytes of private data per signature in the nonce value; heck do the latter and in general your label and similar metadata isn't even going to take up any extra blockchain space. Payment protocol stuff would be more bulky unfortunately, but one can always compromise.

What's really attractive with this idea is you can have your cake and eat it too: an HD wallet that has additional data stored on the blockchain can now have private keys added to it after the fact, for instance from the act of sweeping coins from a scanned private key.

1) Accounting data is of course never modified, only appended too.

Of course there are good reasons. Most obviously, you want to frequently update your backup. Remember - this is not just about keys. Each time you send or receive money the transactions change, possibly get labelled and so on.

That's without even thinking about the ridiculous pile of code it would take to implement such a thing.

I'm sure you love the idea of constructing some convoluted argument about how abusing the block chain for file storage must be the most rational thing to do, but it's just not under any reasonable approach to systems engineering.

That's nice and all, but I hope you understand my point that from the user's point of view there is no strong reason not to use the blockchain for that purpose other than the very minor cost.


...reliability being essentially 100% with blockchain storage.

The HD seed will be very useful to make "HD wallet specific stuff" yes but it seems cleaner to put "the stuff" somewhere other than the blockchain for the usual "the blockchain is not your personal dropbox" reasons.

For instance one idea for wallet backups is:

1) Like you suggest, create an AES key based on the wallet seed.
2) Encrypt the wallet using the derived AES key.
3) Derive a wallet identifier (derived from a different hash function but still using the seed).
4) Put the encrypted wallet "somewhere" using the wallet identifier as the lookup key.

When you want to recover the wallet you can find it using the wallet identifier and decrypt it using the AES key, both of which are derived from the seed.

The "somewhere" can be a multitude of places. The difficulty is in the actual engineering of "the place that you store it" and things like spam abuse, reliability etc.

I'm not going to make myself popular by saying this, but the blockchain is a very effective way to store private keys when people upgrade their wallets to HD. Just derive a tag from the HD seed with T=H('multibit wallet tag' + seed), encrypt the private keys with AES using the seed as a key, and create some transactions putting that data into the UTXO set with CHECKMULTISIG:

1 tag 3 CHECKMULTISIG

"data" can be up to 120 bytes, 240 bytes in total per txout. Because we've used a tag it's easy for a SPV node to retrieve it later by adding the tag to their bloom filter; make sure the key birthday in the seed is prior to when the private keys are backed up. If you want to be nice you can use OP_RETURN to encode the data, or derive a spendable pubkey to use as the tags instead and spend the outputs. (a bit cheaper too)

There's no reason not to implement this, at least from the point of view of your users.

Programmers do tend to be a bit incomprehensible.

For partial quotes I must admit I quote the whole lot and then just start deleting.

The target audience is people with 'general PC knowledge' hence the overall simplification.

yes people like me who don't know what the hell you programmers are talking about

 btw can anyone explain how to partial quote?