Going forward: MultiBit HD and MultiBit Classic

[jim618]

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.

[1713918779]

1713918779

[1713918779]

1713918779

[1713918779]

1713918779

[garyrowe]

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!

[melon]

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

[Mike Hearn]

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

[jim618]

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.

[melon]

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?

[jim618]

Programmers do tend to be a bit incomprehensible.

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

[Peter Todd]

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.

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 <data> <data> 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.

[jim618]

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.

[Peter Todd]

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.

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.

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.

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

[Mike Hearn]

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.

[Peter Todd]

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.

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.

[bitcoindaddy]

It will probably also start nagging you to move your bitcoin over to an HD wallet.

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.

[jim618]

Fair point

[nomailing]

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"

[jim618]

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 !)

[boozezela]

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

[jim618]

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.

[boozezela]

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.

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" ?

[jim618]

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)