jim618



Offline



Activity: 1708

Merit: 1000









LegendaryActivity: 1708Merit: 1000 Going forward: MultiBit HD and MultiBit Classic September 30, 2013, 03:59:40 PM #1



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.

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: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:(this document will probably take me this week to write - it is all over the place at the moment).MultiBit HDsupport the existing MultiBit random key wallets.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. MultiBit HD Lightweight desktop client. Bitcoin Solutions Ltd Bespoke software. Consultancy.

melon



Offline



Activity: 134

Merit: 100









Full MemberActivity: 134Merit: 100 Re: Going forward: MultiBit HD and MultiBit Classic September 30, 2013, 05:16:30 PM #3 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 Once was a man his name was Jed..had a lot of hair but it wasn't on his head !

jim618



Offline



Activity: 1708

Merit: 1000









LegendaryActivity: 1708Merit: 1000 Re: Going forward: MultiBit HD and MultiBit Classic September 30, 2013, 05:41:17 PM #5 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.



MultiBit HD Lightweight desktop client. Bitcoin Solutions Ltd Bespoke software. Consultancy.

melon



Offline



Activity: 134

Merit: 100









Full MemberActivity: 134Merit: 100 Re: Going forward: MultiBit HD and MultiBit Classic September 30, 2013, 05:57:55 PM #6 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? Once was a man his name was Jed..had a lot of hair but it wasn't on his head !

Peter Todd



Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: Going forward: MultiBit HD and MultiBit Classic September 30, 2013, 06:44:20 PM #8 Quote from: jim618 on September 30, 2013, 05:41:17 PM 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. 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:"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. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

jim618



Offline



Activity: 1708

Merit: 1000









LegendaryActivity: 1708Merit: 1000 Re: Going forward: MultiBit HD and MultiBit Classic September 30, 2013, 07:11:53 PM #9 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. MultiBit HD Lightweight desktop client. Bitcoin Solutions Ltd Bespoke software. Consultancy.

Mike Hearn



Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: Going forward: MultiBit HD and MultiBit Classic October 01, 2013, 09:31:46 AM #11 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



Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: Going forward: MultiBit HD and MultiBit Classic October 01, 2013, 10:51:57 AM #12 Quote from: Mike Hearn on October 01, 2013, 09:31:46 AM 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. 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. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

nomailing



Offline



Activity: 126

Merit: 100







Full MemberActivity: 126Merit: 100 Re: Going forward: MultiBit HD and MultiBit Classic October 16, 2013, 05:08:45 PM #15 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" BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR

boozezela



Offline



Activity: 35

Merit: 0







NewbieActivity: 35Merit: 0 Re: Going forward: MultiBit HD and MultiBit Classic October 30, 2013, 12:12:08 AM #17 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



Offline



Activity: 1708

Merit: 1000









LegendaryActivity: 1708Merit: 1000 Re: Going forward: MultiBit HD and MultiBit Classic October 30, 2013, 05:09:12 PM #18 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. MultiBit HD Lightweight desktop client. Bitcoin Solutions Ltd Bespoke software. Consultancy.

boozezela



Offline



Activity: 35

Merit: 0







NewbieActivity: 35Merit: 0 Re: Going forward: MultiBit HD and MultiBit Classic November 01, 2013, 02:45:19 AM #19 Quote from: jim618 on October 30, 2013, 05:09:12 PM 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" ? 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 ain 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" ?