Topic: MultiBit - page 68. (Read 336309 times)

Why dont you just create a new wallet on the TC drive to begin with?

Until MulitBit supports built-in encryption, here's a workaround: create a separate wallet with your 'savings', and (after closing MultiBit) move that to a truecrypt drive (or partition, or container, etc). Unmount this drive and don't open it again until you actually need to get money out of your savings.

Next time when you start MultiBit, you'll see a warning that your 'savings' wallet is missing. That's correct (cause this wallet is now on your truecrypt drive which is no longer mounted). Keep your pocket change in a regular wallet, and if you copied the addresses (not the private keys!) from the savings wallet when you initially created it, you can still see their balance online on various sites such as blockchain.info.

You can still keep sending money to your savings account (you only need its public address for that) without ever accessing the encrypted storage.

Thanks for the quick reply jim.

If i knew java I would help.... but I am just a Ruby/ex-c# guy.

Hi ErebusBat,

Yes you are correct, the lack of encryption on the MultiBit wallets is currently its biggest weakness. Some thoughts:

1) I recommend people keep their 'savings' BTC in the Satoshi client and keep relatively small smounts in MultiBit. This is what I do.   
2) Having FileVault switched on for your personal folder keeps your wallets encrypted when your machine is locked/off but does not help when you are logged in / running MultiBit.
3) Similarly you can have your wallets in a Trucrypt volume but they are still vulnerable when the Trucrypt volume is mounted.
4) You can also have MultiBit and your wallets on a USB drive, as described here:
http://multibit.org/help_runFromUSBDrive.html
Again, when your USB drive is plugged in and decrypted (if you use TruCrypt in addition) your wallets are still vulnerable to a Trojan.

Wallet encryption is my number one priority to work on as none of the above are satisfactory.

I have the UI work detailed here:
https://docs.google.com/document/d/1_8vwkQcv-Tcfx9aU-lKbWgDhAsOkpug3wiHyTo2sy0Y/edit?pli=1#heading=h.kd3tu753qxq
There are few things to do (including some necessary wallet data changes) but it should be 'just' a matter of working through them.

Jim

tl;dr:  Encryption Question
MultiBit seems to be the best full client for my OS (OSX); however the lack of encryption makes me leary.

What is current the best way to mitigate that?  Just use a TrueCrypt volume?  Doesn't that leave my coins at risk when I want to monitor TXs, but not send?

Please advise,

Thanks!

Hi flatfly,

Thanks !

For memory, I had a look a while ago and the MultiBit process when it had a 'few, smallish' wallets open and fully synced it was about 120MB RAM.

Wallets with several hundred transactions now store at around a megabyte but in memory the structures will be less efficient.

I think normal users would be able to run it on a device with 256MB RAM no problem.

Storage wise I worked out that MultiBit would not quite fit on a 256MB USB drive (mainly due to the size of the JRE) but would fit happily on a 512MB one. Edit: that was for a completely portable version ie windows plus Linux JRE and all the help stored locally. For a normal install the 150MB you have on your comparison chart is plenty.

I have a Raspberry Pi on order as I reckon it should run on that ok.

Cheers

Nice release!
By the way, how much RAM is it recommended to have (on Windows, for instance)?

Yeah, Tim and I have been looking at it.
Seems that sometimes MtGox just does not serve up the data - presumably when it is busy.

I'm still on 0.3.5 and its working fine for me.

I noticed this morning that the currency ticker has stopped picking up the MtGox data.
I have mentioned it to Tim Molter (the author of the XChange code that MultiBit uses to get the ticker info).
It is most likely that the ticker information from MtGox has changed in some way.

You can see the raw feed if you are interested at:
https://mtgox.com/api/1/BTCUSD/ticker?raw

Great - thanks speedbus.

I am hoping that (other than some more information in the wallet details panel) people will not see much difference, except that any new wallets they create are smaller and load quicker.

Awesome !! Will upgrade ASAP !!

There is a new release of MultiBit at:

http://multibit.org


Version 0.4.0

Enhancements:
+  Introduction of protobuf format for new wallets
+  Upgrade to bitcoinj v0.5.1 library
+  Upgrade to XChange v1.01 library
+  Added Message window
+  Minor UI improvements to help browser

Release info
Scan of release checklist


Note: Protobuf wallets you create with MultiBit 0.4.0 are NOT readable in earlier versions of MultiBit

Next up will be a conversion utility to convert old wallets into the new format.

Protobuf wallets are a lot easier to add new data to compared to the old format which was quite brittle.
At the moment the new format has identical functionality to the old so it does not have encryption yet.

I thought it would be safest to migrate everyone over to the new format first before adding extra things. There are now thousands of MultiBit wallets in existence so I am doing it one step at a time.

When the encryption goes in (next thing after migrating the old wallets) it will be encryption of the private keys yes. You will be able to see the balance and new transactions will be received always.

Then when you want to spend you will have to type in your password. It will be a field on the 'Send confirm' screen.

There are also some discussions needed with other bitcoinj devs to get agreement on how the encryption is done and stored as the protobuf wallet format is shared amongst all bitcoinj users. A good data format would mean other bitcoinj users will be able to use the encryption functionality easily in their apps.  I am proposing to use the same encryption I use with the private key export as that is already working and you can use OpenSSL to do the decrypt (ie you can decrypt outside of MultiBit if you want).

Edit: In addition, you can also read and write protobuf data with other languages like C++, python and C so potentially non-Java devs could use the same wallet storage format. The wallets would all be interoperable.

And protobuf = new small wallet format that also supports encryption? (and the password for decryption is only required if I want to make payments from that wallet, not just when checking its balance?)

The main change in the next version of MultiBit is that there is a new wallet format, called 'protobuf'.

In the wallet detail callout (that you get by clicking the twisty in the wallet panel) I have put in an extra tooltip and drill-down help to explain it.
Here is a screenshot:



Hopefully that will be clear to everyone. The 'wallet formats' help will also be a heading in the main Help Contents page.

The next version (v0.4.0) should be out in the next day or two - just spending a bit of time user testing it before it goes on the website.

Ok i will see if i can make some time this weekend, i just have a newborn and am moving to a new home, so its a little bit hectic

Hi bitcoinspot.nl,
Thanks for asking !
There have been a few strings gone in recently to do with the new Message window. The type of wallet is now localised too - though localising 'serialised' and 'protobuf' will be a challenge! (probably best just to treat them as loan words).

I think I will release what I have now quite soon. I have done:
+ new wallets are created/saved/loaded in the new protobuf format
+ old wallets are loaded and saved in the old format i.e. No change.

At the moment there is no auto-upgrade from old -> new. (that will come next once I have done a utility to loop over the old format wallets to test and validate saving in the new format: backup old : write new).

I think I will QA what I have now and release it so that, for new wallets and users, we start using the new format. I will aim to release it, say, Monday next week giving the weekend for 'testing and tidying' (for me) and time for any localisation you want to do.

oops didnt read my inbox

Any additional translation needed before the next version?