I have found and fixed a bug in 0.5.9rc1:
If you open a wallet that is already open MultiBit freezes and you have to force quit it.
Now fixed so that the already opened wallet is selected as the active wallet.
Topic: 0.5.9 feedback (Read 924 times)
All those options sound like great improvements. I agree the delete option is dangerous, though I understand why it may be useful. Definitely a power tool that you can easily cut your own arm off with.
Some changes from testing 0.5.9:
+ The key.type persistence error mentioned in the previous post is legitimate (there is now a new category of key.type for encrypted keys that was not in 0.5.8. It prevents earlier versions of MultiBit reading encrypted wallets so is a good thing).
+ The Mac app is now signed with a developer key in the name of "James Burton". There is also a fix gone in to improve text display on Mac retina displays which was fuzzy.
+ By default the 'File | Delete Wallet' option is not being shown. There is a config option (showDeleteWallet=true) that you can add into the multibit.properties to get it back. I have done this mainly to protect new users from themselves. There have been a couple of instances where a user has deleted their wallets, and confirmed they wanted to delete them, and then realised they had made a mistake, typically with change addresses. In the 'Delete confirmation' dialog I have also put in a challenge question: "Enter the creator of Bitcoin" where you need to type "Satoshi Nakamoto" for the delete to take place. This is to stop your darling 5 year old daughter from deleting your wallet when she is playing around trying to get her favourite Disney cartoon to play.
+ I have removed the twisty and the wallet call out panel with the filename and file type in. This is just to simplify things. The filename of the active wallet is shown in the title bar of the whole MultiBit window and the filetype (protobuf/ serialised) was a bit geeky and not needed for the normal user.
+ The key.type persistence error mentioned in the previous post is legitimate (there is now a new category of key.type for encrypted keys that was not in 0.5.8. It prevents earlier versions of MultiBit reading encrypted wallets so is a good thing).
+ The Mac app is now signed with a developer key in the name of "James Burton". There is also a fix gone in to improve text display on Mac retina displays which was fuzzy.
+ By default the 'File | Delete Wallet' option is not being shown. There is a config option (showDeleteWallet=true) that you can add into the multibit.properties to get it back. I have done this mainly to protect new users from themselves. There have been a couple of instances where a user has deleted their wallets, and confirmed they wanted to delete them, and then realised they had made a mistake, typically with change addresses. In the 'Delete confirmation' dialog I have also put in a challenge question: "Enter the creator of Bitcoin" where you need to type "Satoshi Nakamoto" for the delete to take place. This is to stop your darling 5 year old daughter from deleting your wallet when she is playing around trying to get her favourite Disney cartoon to play.
+ I have removed the twisty and the wallet call out panel with the filename and file type in. This is just to simplify things. The filename of the active wallet is shown in the title bar of the whole MultiBit window and the filetype (protobuf/ serialised) was a bit geeky and not needed for the normal user.
I noticed tonight that if you try to open the 0.5.9-SNAPSHOT encrypted wallets in 0.5.8beta you get the error:
Could not load the wallet file "/Users/jim/real money/pettyCash3.wallet".
The error message was "com.google.protobuf.InvalidProtocolBufferException Message missing required fields: key[0].type, key[1].type, key[2].type, key[3].type, key[4].type, key[5].type, key[6].type"
You can still open the wallets in 0.5.9-SNAPSHOT so it is more annoying than anything.
It looks like I am not saving the key.type field correctly for encrypted wallets when writing the wallet to disk so I will fix that for the release candidate.
Could not load the wallet file "/Users/jim/real money/pettyCash3.wallet".
The error message was "com.google.protobuf.InvalidProtocolBufferException Message missing required fields: key[0].type, key[1].type, key[2].type, key[3].type, key[4].type, key[5].type, key[6].type"
You can still open the wallets in 0.5.9-SNAPSHOT so it is more annoying than anything.
It looks like I am not saving the key.type field correctly for encrypted wallets when writing the wallet to disk so I will fix that for the release candidate.
Hi Mike,
Yes it is exactly that.
One chain per wallet would improve the user experience at the expense of a bit more IO. I think that is a good idea.
If it is _exactly_ synced to the block it opens and does not sync but otherwise it works out the date to sync by (in order)
+ lastSeenBlockHeight
+ date of last confirmed tx
+ wallet birthday
Then (currently) it will go back to the last checkpoint before that date/ height to actually start downloading the blocks.
The sync work is a "simple first version" really. There is also scope for improvements when there are queued sync tasks to consolidate them for instance. I thought I would do the simplest version first and get that out and get feedback.
I had thought of having a separate PeerGroup for just the re-sync but that seemed unnecessarily complicated.
Also, it is quite useful that the other wallets will get any transactions they missed in any resync as they are all listening to the download Peer too.
I think for the 0.5.9 version I'll stop adding new features though and consider it to be in a code freeze. i.e only fix bugs, improve the tests/ docs etc.
edit: Also the checkpoints file needs to be downloaded to keep it up to date. This will be from multibit.org and threshold signed in the same way as the version.txt when we get that all set up.
Yes it is exactly that.
One chain per wallet would improve the user experience at the expense of a bit more IO. I think that is a good idea.
If it is _exactly_ synced to the block it opens and does not sync but otherwise it works out the date to sync by (in order)
+ lastSeenBlockHeight
+ date of last confirmed tx
+ wallet birthday
Then (currently) it will go back to the last checkpoint before that date/ height to actually start downloading the blocks.
The sync work is a "simple first version" really. There is also scope for improvements when there are queued sync tasks to consolidate them for instance. I thought I would do the simplest version first and get that out and get feedback.
I had thought of having a separate PeerGroup for just the re-sync but that seemed unnecessarily complicated.
Also, it is quite useful that the other wallets will get any transactions they missed in any resync as they are all listening to the download Peer too.
I think for the 0.5.9 version I'll stop adding new features though and consider it to be in a code freeze. i.e only fix bugs, improve the tests/ docs etc.
edit: Also the checkpoints file needs to be downloaded to keep it up to date. This will be from multibit.org and threshold signed in the same way as the version.txt when we get that all set up.
By the way, I played with it more later. The resyncing thing seemed to work pretty well. Though when opening a wallet, it always resynced from a month or so ago, even if it was synced last time I closed it. I assume this is syncing from the last checkpoint because there's only one chain file?
I wonder if nowadays it makes more sense to keep one chain for each wallet, given that it's quite small.
I wonder if nowadays it makes more sense to keep one chain for each wallet, given that it's quite small.
Also in Multibit 0.5.9-SNAPSHOT is a fix for installing when the version of Java is 64 bit:
https://github.com/jim618/multibit/issues/89
I've checked (on a Win XP VM) that this has not broken the Win install but don't have a Win64 machine to test it out on.
Can someone with a Win64 version of Java try it out please ?
https://github.com/jim618/multibit/issues/89
I've checked (on a Win XP VM) that this has not broken the Win install but don't have a Win64 machine to test it out on.
Can someone with a Win64 version of Java try it out please ?
Hi Mike,
Thanks for the feedback.
I have only signed it with my GPG sig. I need to pay my 'code tax' and get Mac and Win developer licences. I'll get those sorted as it is stupid not to have them at this point.
The protobuf/ serialised stuff can go now as serialised isn't supported. (you have to migrate using an older version of MultiBit: in https://multibit.org/releases )
The documentation / help will need a bit of tidying up. I normally do that a few days after the release I must admit. It does not mention much about the automatic sync for instance.
Also will put in a help topic for what all the files are on disk as a couple of people have asked about that.
Thanks for the feedback.
I have only signed it with my GPG sig. I need to pay my 'code tax' and get Mac and Win developer licences. I'll get those sorted as it is stupid not to have them at this point.
The protobuf/ serialised stuff can go now as serialised isn't supported. (you have to migrate using an older version of MultiBit: in https://multibit.org/releases )
The documentation / help will need a bit of tidying up. I normally do that a few days after the release I must admit. It does not mention much about the automatic sync for instance.
Also will put in a help topic for what all the files are on disk as a couple of people have asked about that.
Hey Jim,
The Mac version seems to be incorrectly signed, such that Gatekeeper refuses to open it. Are you signing the packages with a developer ID certificate? Gavin put a fair bit of effort into getting Bitcoin-Qt signed and working with Gatekeeper, it'd be hard to downgrade that now, especially as the usual right click+open trick doesn't work on signature-failing apps. You have to disable Gatekeeper entirely.
Maybe because I installed an Oracle JVM, but I see blurry text (not retina compatible). There's a simple hack that can fix this, see here:
http://stackoverflow.com/questions/13003511/eclipse-juno-and-retina-resolution
It won't do much for the artwork but will fix the text, which is the most important thing.
Should the help documentation talk about protobuf vs serialized? That seems a bit nerdy.
Otherwise seems to be working OK! Will continue testing.
The Mac version seems to be incorrectly signed, such that Gatekeeper refuses to open it. Are you signing the packages with a developer ID certificate? Gavin put a fair bit of effort into getting Bitcoin-Qt signed and working with Gatekeeper, it'd be hard to downgrade that now, especially as the usual right click+open trick doesn't work on signature-failing apps. You have to disable Gatekeeper entirely.
Maybe because I installed an Oracle JVM, but I see blurry text (not retina compatible). There's a simple hack that can fix this, see here:
http://stackoverflow.com/questions/13003511/eclipse-juno-and-retina-resolution
It won't do much for the artwork but will fix the text, which is the most important thing.
Should the help documentation talk about protobuf vs serialized? That seems a bit nerdy.
Otherwise seems to be working OK! Will continue testing.
Jump to: