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. ;-)

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

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.

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

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.

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.

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.exeoraFunnyPic.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).

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

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.

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

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?