Topic: Going forward: MultiBit HD and MultiBit Classic (Read 11174 times)

Its probably a bit late for extra features right now.... just in case 

One of the things i'd really like more control over is the individual balance of my addresses within a wallet. It would be very useful to have the ability to view balances for individual addresses and to a limited extent, craft transactions from whichever pool of coins i'd like to spend.

I also wondered about the possibility of adding a user defined 2FA for a high security wallet. say with an e-mail of better still a bitmessage confirmation code.??

My biggest user gripe is actually much more down to earth. I find myself accidentally renaming send addresses or worse writing over the destination address. A simple 'lock field' feature for trusted addresses would be awesome. 

These would be awesome to see. The 'Advanced mode' for multibit could be very functional.

I was also wondering if the import 'classic' wallet into HD could be sent through coinjoin as an option? If we have to use a whole set of new addresses they may as well be taint free.

Then you'll be waiting a long time 'cause with deterministic wallets exporting private keys for individual addresses is dangerous. See this article from vbuterin:

http://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/

Will you be including features like multisig, coinjoin, and stealth addresses?

That's right - there is no seed so you need copies of the private keys in all your wallets.

I recommend both copying the wallet (and the subdirectories with all the backups in) AND making a private key export.

You only really need one or the other but the only time you'll use a backup is when Something Bad Happened so make both sorts of backups just in case.

This may seem like a silly and basic question, but I have most of my coins stored on 2 different laptops with 2 different MultiBit accounts.  If I export private keys to a USB drive is that enough should one of my computers ever crash or get infected?  I'm assuming no seed on MultiBit classic, correct?

Thanks for any help!

We've got it sending and receiving etc now but still have things like all the Preferences to do.

At the moment we have a 'placeholder' deterministic wallet that is very simple - Mike's going to be working on the HD wallet support in bitcoinj throughout March.

We don't really want people (except early beta testers) using it until we have proper HD wallets in as it will no doubt cause problems for people when the formats change.

It's still 'bleeding edge' at the moment.

thanks for your hard work mate..
any eta??

Thanks for your enthusiasm !

We are busy "baking the cake" at the moment, but like all things it takes a while.

i want multibit HD

MultiBit HD and MultiBit Classic will both be able to operate side by side. Our recommended upgrade path would include a "sweep" of all funds out of MultiBit Classic and into MBHD. This would not be part of the standard install wizard, but rather something the user would do at their discretion through a simple "Request Bitcoin" operation.

Once that has confirmed then the user would be free to archive/uninstall MultiBit Classic. We would obviously recommend that people not delete any private keys in case someone ever attempts to send them funds through an old address. In that circumstance a user would be able to reinstall MultiBit Classic (we will provide maintenance releases and an archive) to open their old wallets and sweep those funds.

At present we have no plans for a combination of HD wallet with a few private keys mixed in. This is because people should not be reusing standard addresses (I know we're all guilty of it, but it leaks privacy). It will also cause more complexity within the code that will incur development effort.

My input would be to have the ability to install Multi-bit in addition to Miltibit classis,  then its just a matter of sending btc over to the new HD wallents.  Once Miltibit classic is empty it can be uninstalled .  Maybe some fee grace for this, makes it simple.

My last upgrade to the latest version went so smooth I was amazed,  it has to be that easy.

For the love of God, give me the ability to put all the files together with the executable.

Better: instead of having to create a .properties file (like with multibit "classic") within the same directory where the Multibit HD executable is/will be, create one there by default.
Then give an advanced used the possibility to make portability happen just by changing a simple flag. Something like this:


And pick the location for the rest of the files accordingly.

So i will waiting for this future day when I can export pure private and public keys  for all my addresses   

Yes you can just use the mnemonic phrase to recreate your wallet (though it will have to replay the blocks from when you created it so eventually this will take a while).

The cloud backups you can simply not set up yes.

I expect the first version won't be able to import and export extended public and private keys but it would be a great feature to be able to choose which 'sort' you want to export and import.  It will be a bit difficult to explain it to people in a simple fashion though so we might have to put in an 'Advanced' mode or something.

TBH I am not sure how and what we are going to provide in address management yet. We are still thinking about it.

You should be able to run it from a memory stick yes. It will have a Jave runtime in it so it should be better.

We are still playing around with the UI so don't really want to show it yet. It is still early days for it yet so there is still a lot to do in it yet.

Ok, that sounds much better. So I don't need any backup at all to restore all my bitcoins from the mnemonic?
Then, I will prefer to not upload my wallet to a cloud, because I am more afraid of someone breaking into some cloud storage and stealing my coins.

Am I correct that Multibit HD will support my user behavior as follows:
I use Multibit HD on a linux live cd and always backup my wallet file on an external usb drive.
In case of a corrupt usb drive I will still be able to recover my coins using the mnemonic phrase. Of course then I will lose the additional contact infos and labels which I stored in the wallet, but this is only in case my usb stick is corrupted. Correct?

Another question: Can I then export an extended private key, which I can import in some android app to have a small fraction of my coins in a spendable wallet?

hi, i'm just wondering if Multibit HD will be able to freeze addresses - like the Electrum wallet does...

also, i'm running multibit from a memory stick, will this be an option for HD ?

incidentally, are there any images of the new look/layout fo HD ?

You are correct that with the mnemonic phrase you can reconstruct all the private keys.   

Why have wallet backups?

1) There is more data in a wallet than just private keys (and there will be more in the future). For instance: you can give someone an extended public key and they can put in their contact info they keep on you. Then they can create addresses to send bitcoin to you. Only you and they know the generated addresses are related. It's private, even though it is on the blockchain.

2) We want triple redundancy for the critical wallet info. Namely:
+ Wallet seed
+ Local backup
+ Cloud backup

Each technique may give us '2 or 3' nines of reliability so, in combination, it should be good enough for rolling out to 1,000,000+ users. We don't want a single user losing bitcoin.

If this is true, then I don't understand why it is necessary to have a wallet backup at all.
Why couldn't it work without a wallet backup?

For example, why not like this:
mnemonic phrase -> seed -> master private key -> all-your-private-addresses

This would work on a live-cd without having any wallet backup stored on any cloud or whatever. Just a simple list of 12 words...

EDIT: Or if you want to use 256 bit security in BIP 32 then you use 24 words in BIP 39.

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?

Hi Mike,

Where someone has an existing (random key) wallet I can't see a way of showing it / using it in MBHD without there being individual random private keys that need backing up.

If the message to the user is 'write these words down and you can get your bitcoin back' that is relatively simple.
You could say 'oh everything is in the cloud' but that will have a non-trivial failure rate eg:

'Oh I never set that up'
'Oh I wondered what those firewall messages were'

I figure if we have all of:
+ HD wallets only with strong insistence to write your seed mnemonic down.
+ local backups (basically the backup system that is in MultiBit now)
And
+ cloud backup of an encrypted copy of your wallet

(Ie  triple redundancy)
Then the overall failure rate (meaning a loss of bitcoins) will be as low as possible.

Then when trezor comes onstream the attacks from having a compromised host computer also go down. As trezor only supports HD wallets it seems to make sense to only offer those.

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

MBHD should be able to import existing wallets. I don't intend to break backwards compatibility for HD wallet support at least.

the naming convention used is a plus and easy to understand...good explanation as always going forward so users are aware of whats happening..thumbs up

While we're working out the new UI for MultiBit HD, we'd appreciate any feedback from MultiBit users about features you'd like to see and stuff you'd hate to see.

We can't guarantee that anything will find its way in but if enough people get together to ask for it then we'll certainly take that into account. Of course, pledges and sponsorship go a *very* long way to ensuring that your issue gets attention. :-)

Overall, the reasons for doing this are:

1) to reduce private key loss to near zero through hierarchical deterministic (HD) and hardware wallet support

We can't say exactly zero because someone, somewhere will ignore the messages to write down their seed phrase and we can't code for that. We will not be supporting random private keys in MultiBit HD.

2) to get away from Swing and the horrible Oracle Java installer

We will continue to use Java (the open source support libraries are vast) and Bitcoinj.

Tell us what you think in the comments!

Gary and I, amoungst other things, had a long chat at the Bitcoin Conference in Amsterdam over the direction to take MultiBit.

We reckon HD wallets are going to be much easier for users compared to the existing random key wallets. Even with all the work in MultiBit with backups there are still too many people losing their private keys and there are too many errors caused by importing and exporting private keys.

What we plan to do is to fork the MultiBit code so that there will be:

MultiBit HD
This will be a new UI where the user can create an HD wallet and do all the 'deterministic wallet' things.
This will also include the Trezor support (which uses HD wallets internally).

I have started writing the use cases for this here:
https://docs.google.com/document/d/18qtE5lmRzB32Sc9Ii37GySJGLKx3VNypBkjnHbNjdik
(this document will probably take me this week to write - it is all over the place at the moment).

MultiBit HD won't support the existing MultiBit random key wallets.


MultiBit Classic
The existing MultiBit code will be renamed to MultiBit Classic.
It will still be maintained for things like network access and if the fee structures change but there won't be any real development of it going forward. It will probably also start nagging you to move your bitcoin over to an HD wallet.