MultiBit

[CogSci]

I've been playing with this beta version (0.5.7) a bit yesterday. Please help me understand this password protection feature! It seems like when I open a wallet that I created with 0.4x, and add a password to it, this beta version does a backup of my wallet, plus one password protected version. Now, there is no point of having a wallet password protected, while at the same time I have an unprotected (backup)version floating around in the same folder(?). So, which file(s) do I need to move to a saver place, if any, to have only the password protected wallet in my working folder? Or maybe I misunderstood the whole principle? BTW, I'm on Kubuntu, if that makes a difference, and yes, I have multiple backups at save places. ;-)

[1714196646]

1714196646

[1714196646]

1714196646

[1714196646]

1714196646

[1714196646]

1714196646

[jim618]

Hi CogSci,

That is very observant of you. I don't think anyone else has noticed exactly what the MultiBit wallet writing strategy is.

There are two separate things going on simultaneously:

1) Whenever MultiBit saves a wallet (say: example.wallet) it does the following:
    1.1 Copies the existing example.wallet to a timestamped backup. (Something like example-20130123182701.wallet.)
    1.2 Writes the wallet that is in memory to the file example.wallet.
    1.3 Secure deletes the previous timestamped backup that it wrote the last time it saved the wallet. (There is only one level of backup).

It does this every time it writes the wallet, for any reason.
The reason for doing this is so that if 'something bad' happens (eg immediate power loss) you will always have one good copy of the wallet, even if it is one write out of date. When you start MultiBit if the expected wallet is missing it will automatically load the backup.

2. When you encrypt a wallet it encrypts all the keys with your password and writes the wallet. You then have:
    2.1 the example.wallet encrypted.
    2.2 the backup wallet will be the version before the encrypt, which is unencrypted as you state correctly.

The next time the wallet writes you will have:
3.1 The example.wallet which is encrypted together with the latest changes that have just been made.
3.2 The backup wallet is the encrypted wallet from 2.1
3.3 The previous backup (the unencryped wallet from 2.2) is secure deleted by overwriting all the bytes with a nonsense pattern and then deleting the file.

The wallets write pretty often (if you change anything on the screens it gets marked as dirty and a background thread will write it within 2 minutes, when a transaction arrives, when a block arrives, immediately if you create a new receiving address, immediately when you do a send) so the unencrypted wallet will disappear from your drive within a few minutes.

I hope that makes sense.
It is a compromise between security and "things that can go wrong will go wrong" driving the need for a rolling backup.

You have probably also noticed that when you encrypt the wallet (or add a receiving address, import keys or change the password) MultiBit also automatically writes a timestamped, encrypted export of the private keys. The export is encrypted with the wallet password. I added this because I found that people didn't appear to be backing up their private keys. This is the number one way to recover your wallet in case of a "bad thing happening" so I thought it was worth being automatic.

[CogSci]

WOW! What a smart system! Thank you for the explanation! Makes perfectly sense.

[jim618]

Thanks !

Trying to make sure people don't lose their private keys is a challenge (as most people probably don't even know what they are).
For perfect security the backups would not be created but I think in reality they are needed.

Deterministic wallets, with a keyphrase mnemonic, will certainly help here.

[ZoladkowaGorzka]

Is there a limit for generated addresses in wallet?

[Grouver (BtcBalance)]

Hi Jim.
I would like to come back to the Java requirement issue.
We all know an outdated version of Java can get you infected really easy by for instance an infected email.
Since this virus could infect you with a keylogger it could intercept the password of your Multibit wallet.
This reminds me to Mike his suggestion: https://bitcointalk.org/index.php?topic=43616.msg1241820#msg1241820

Is there any process on this important (if you ask me) subject?

Thanks.

[jim618]

Is there a limit for generated addresses in wallet?

There is no fixed limit to the number of generated addresses in a wallet no. With the test code I make it a bit easier to add more than 1 by have a selector for 1, 5, 20, 100 addresses.

The limit is reality is probably to do with how quickly transactions are processed and screen refreshes. This is a bit unknown.
The current code is probably ok up to wallets of, say, 1000 addresses but I expect there would be some snags larger than that as it is unexplored territory.

[jim618]

Hi Jim.
I would like to come back to the Java requirement issue.
We all know an outdated version of Java can get you infected really easy by for instance an infected email.
Since this virus could infect you with a keylogger it could intercept the password of your Multibit wallet.
This reminds me to Mike his suggestion: https://bitcointalk.org/index.php?topic=43616.msg1241820#msg1241820

Is there any process on this important (if you ask me) subject?

Thanks.

Hi Grouver,

I had a look at the Jet website and it is a possibility as it is free for non-commercial use.
I haven't taken it any further though.

It would be important I guess if you had an outright ban on Java running on machines (say in a corporate environment).
A keylogger would be a threat to any Bitcoin wallet should it get onto your machine.

Hardware wallets (like Trezor) might help in this regard as the authorization is on the device.
But TBH if your machine isn't secure it's pretty difficult to defend against.

[Mike Hearn]

As I pointed out before, Java is only a security issue when it's exposed to random untrusted code, like via a web browser plugin.

[jim618]

Yeah - I was going to follow up on Mike's point too:

Java in browser = switch it off to stop random code running in your browser.

A signed Java application running on your machine = you are only running code you know about.

[Grouver (BtcBalance)]

So whats about the hundreds of different viruses you can get via an email that may infect you if your Java is not updated then?
Am I missing something here?

[jim618]

So whats about the hundreds of different viruses you can get via an email that may infect you if your Java is not updated then?
Am I missing something here?

You are correct but I think you are talking about another attack.
Imagine you have an attachment called:

aFunnyPic.jpg.exe
or
aFunnyPic.jpg.jar

and have the setting on to not to see extensions you know about.

Then these look like:

aFunnyPic.jpg

If you double click it to open it, the exe/jar will try to open (well, maybe, I guess it depends on your mail program/ system settings).
If you run a process on your machine then it can do something.
You basically don't want any code you don't know about running on your machine.


Oracle is doing a terrible job keeping people informed about Java vulnerabilities and patching them. I think they are intentionally dragging their feet so that everyone switches it off in browsers etc (then they don't have to support it).

[Grouver (BtcBalance)]

So whats about the hundreds of different viruses you can get via an email that may infect you if your Java is not updated then?
Am I missing something here?

You are correct but I think you are talking about another attack.
Imagine you have an attachment called:

aFunnyPic.jpg.exe
or
aFunnyPic.jpg.jar

and have the setting on to not to see extensions you know about.

Then these look like:

aFunnyPic.jpg

If you double click it to open it, the exe/jar will try to open (well, maybe, I guess it depends on your mail program/ system settings).
If you run a process on your machine then it can do something.
You basically don't want any code you don't know about running on your machine.


Oracle is doing a terrible job keeping people informed about Java vulnerabilities and patching them. I think they are intentionally dragging their feet so that everyone switches it off in browsers etc (then they don't have to support it).

Thats what I mean yes.
So thats why I prefer to not use Java since virus scanners usually lack behind the new virusses that are spread via email.
It normally take them 2 or even 5 days to figure out how to detect the virus and to update there virus database.
Thats why I would like to see an version of Multibit where I don't need to install Java but where its just strapped in when Multibit starts.

[jim618]

Hi Grouver,

I appreciate your concern but it's more work (and more ongoing work as it makes support trickier).
It is tricky enough supporting Win/ Linux/ Mac as it is.
It is a Java program using a Java library after all. The installer is Java too.

If you didn't want it on your machine you could have both MultiBit and a Java runtime on a USB stick.
Or put MultiBit and a Java runtime in a disk/ TruCrypt volume that you only opened when you wanted to run MultiBit.

[lenny_]

Oracle is doing a terrible job keeping people informed about Java vulnerabilities and patching them. I think they are intentionally dragging their feet so that everyone switches it off in browsers etc (then they don't have to support it).

Nowadays, you don't need to even switch if off yourself in your browser. Mozilla Firefox is disabling Java addon competely by default, as soon as it is installed:
https://addons.mozilla.org/en-US/firefox/blocked/p182

[Mike Hearn]

Java makes no difference to viruses that spread via email, I don't know why this comes up.

Java is not a security issue for an app like MultiBit, it's as simple as that.

[ZoladkowaGorzka]

Is there a limit for generated addresses in wallet?

There is no fixed limit to the number of generated addresses in a wallet no. With the test code I make it a bit easier to add more than 1 by have a selector for 1, 5, 20, 100 addresses.

The limit is reality is probably to do with how quickly transactions are processed and screen refreshes. This is a bit unknown.
The current code is probably ok up to wallets of, say, 1000 addresses but I expect there would be some snags larger than that as it is unexplored territory.

Are you planning creating option of exporting/showing master private key? Or is there such option already?

[jim618]

Hi ZoladkowaGorzka,

At the moment the wallets in MultiBit are 'random key' wallets rather than deterministic. Each key is derived from a random number i.e. there is no master private key (like in Electrum and Armory).

The individual private keys you can export into a file using Tools | Export Private Keys.

BIP32 / Hierarchical Deterministic wallets (which will have a master private key) are on the roadmap but they will be a while yet.

[J180]

I am using windows xp. When I try to open my old wallet.dat it just gives a "com.google.protobuf...." error message.

[jim618]

Hi J180,

Is the wallet.dat you are opening a Bitcoin-QT wallet ? I.e. From the main Satoshi cient ?
The format of the wallets is different between clients - you can only open MultiBit wallets in MultiBit.