Topic: MultiBit Classic fails to open wallet file (Read 1069 times)

Ok, I took on the challenge... and figured out what I was doing wrong when trying to decrypt the multibit classic private keys... so I have now added: decrypt_multibit_classic_walletkeys.py to my recovery scripts...  

It works on multibit.wallet files and dumps out the public/private keypairs... should work on both password protected and non-password protected wallets.  

Turns out, I was decrypting them correctly the whole time... I just couldn't get the addresses to match because the python functions I was using to generate addresses was generating the "uncompressed" addresses/keys... whereas MultiBit is using compressed keys... pretty obvious really

Or you should "rescue" your coins and move them to an actively developed/supported wallet... I suspect this issue will be just the tip of the iceberg... and who knows what will start happening when/if SegWit or Hard/Soft Forks start happening...

Somebody should fork mulitbit classic and apply a bug fix. It seems the original developer has abandoned it......

Great stuff!

So the question remains, how to deal with a Multibit Classic wallet file in case one does not have the .key files.

I.e. how to decrypt the information in the wallet file

(That is my case.)

If you are still having issues with your MultiBit Classic... Try this: https://github.com/HardCorePawn/multibit_recovery

I wrote a couple of small python scripts (based on decrypt_bitcoinj_seed by gurnec, the btcrecover guy ) to try and help recover funds from "broken" MultiBit HD and MultiBit classic wallets... If I get some time, I'll write up a guide (with pretty pictures)...

MultiBit Classic is easy, it just decrypts your key-backup file using your wallet password... and dumps out the privatekeys... you can then import them all into another wallet.  
EDIT: There is also a script that works on wallet files now if you don't have a key-backup

MultiBitHD is a P.I.T.A    

You gotta use the BIP39 tool to find all the addresses/private keys for your Seed and hunt through them looking for the ones that still have coins... my script tries to hunt through your mbhd.wallet.aes file looking for unspent transactions to try and narrow down the search....

You can donate here if these scripts help you recover your funds: 1NyVDDmhZPcyKhyrkiUFZbqPPuiYxwTujb

I am suspecting indeed some issue with the version:

I have tried the wallet-tools from bitcoinj on it. I get an error that the wallet is from the future:

"org.bitcoinj.wallet.UnreadableWalletException$FutureVersion: Unknown wallet version from the future."

I can still do a raw_dump, and I see that it says "version 2" for the wallet, and all transactions are "version 1", except one, which is "version 2" (maybe the newest one?)

Note that the wallet-tools is the current version 0.14.4

It is definitely related to that issue... MultiBit Classic is not compatible with newer transactions... following those links you posted earlier to the Google Groups... I found the github commit you were talking about: https://github.com/bitcoinj/bitcoinj/commit/be09b620626681c9e51a211ee314a34cb7958a12

In this commit, they are now setting the "Version" field inside a transaction and it is included when calculating the transaction hash value... however, MultiBit is ignoring this field... so when MultiBit calculates the hash value of the transaction it gets "abc", but the hash value stored in the transaction (including the version) is "xyz"... so it fails rather ungracefully and then MultiBit (HD anyway) gives out the rather generic "Password did not unlock the wallet" error and refuses to load up the wallet.

The only way for this to be fixed, is for MultiBit devs to start using the new version of bitcoinj and start using the Version field...

I think I have figured out a solution for exporting private keys from MultiBit Classic... and I am fairly confident that I have a process (albeit quite tedious) to work out which addresses generated within a MultiBit HD "Seed" have unspent transactions and how to get the corresponding private keys for them...

Some more investigation:

From looking into the MultiBit source code, I have the suspicion that a recent code change to the underlying bitcoinj might
be incompatible with MultiBit Classic:

On github, I see: February 5: WalletProtobufSerializer: Fix protobuf deserialization of transaction version
for the file bitcoinj/core/src/main/java/org/bitcoinj/wallet/WalletProtobufSerializer.java

And indeed in this file the error message I reported is thrown:

line 697: throw new UnreadableWalletException(String.format(Locale.US, "Transaction did not deserialize completely: %s vs %s", tx.getHash(), protoHash));

Does that mean that MBC eventually has a problem reading / writing a recent transaction? The wallet worked fine, until I received a transaction in April 2017, i.e. after February 5. The transaction previous to this one was mid 2016.

Does that give you perhaps a hint how to fix it?

Thanks for your consideration & feedback!

Hello! I been working with multibit Last 2 years. I have it on my computer and owrked nicely.

Today I tried to open my wallet and got Password cant open wallet error.

I have tried many time, i also used words to show me it, and it match, so my password is OK. but multibit is not working, and giving me password error.

What Can i Do?

I have some coins, please help urgent. PLease what can i do???

Thanks for highlighting this! It all makes sense now...

MultiBit HD also seems to be suffering from the same issue... There have been a large number of users around here getting the "Password did not unlock the wallet" error with the associated "Transaction did not deserialize completely" error in log.

I had got as far as figuring out that it was a hash conflict, but couldn't figure out why the computed hash was different... obviously adding in a new field will cause that

In the meantime, the only way to get access to your funds would be to import the private keys to another wallet... I've figured out a method for MultiBit HD, as you can use the BIP39 tools to derive your keys from the seed... but I've not looked at Classic as yet... hopefully the wallet file can be decrypted in a similar fashion to the HD one...

Could the problem be related to this issue?

https://forum.bitsquare.io/t/restore-a-corrupted-wallet/1709/6
(and link to google groups in there)

(in which I case I would conclude that MultiBit Classic would need an update for being able to read recent transactions??)

Thanks for your reply!

I had seen the other post, but it did not help me: How can I export the private keys, if the wallet is not opening?

I have tried also version 0.5.19, but the same issue occurs there.

And of course, I will move to a more modern wallet, but since I cannot import a wallet file directly, it does not solve my issue. And from reading up on 'btcrecover', I see
that also this tool will need the private keys in dedicated files, not the wallet file.

Is there any tool to extract the keys? (I know the password of course.) Or what other route could I take?

Thanks for helping!

It seems as if you were not the first to have the problem.
https://bitcointalksearch.org/topic/weird-problem-with-multibit-classic-0519-0518-1805737

Perhaps the solution from the thread helps you.

Regardless of the problem, you should update to 0.5.19 or switch directly to Multibit HD.

Does anyone have a hint how to make MultiBit open its wallet file / knows why this fails?

The error message is:

"com.google.bitcoin.store.UnreadableWalletException Transaction did not deserialize completely"


---------------------------

Bitcoin Client Software and Version Number: MultiBit Classic 0.5.18
Operating System: Mac OS X 10.11.6
System Hardware Specs: N.A.
Description of Problem: MultiBit fails opening its wallet file, and also the backup file will not open.

Any Related Addresses: N.A.
Any Related Transaction IDs: N.A
Screenshot of the problem: N.A.
Log Files from the Bitcoin Client: N.A

On each attempt to open the file, one gets this error:

09:38:44.485 [AWT-EventQueue-0] DEBUG o.m.v.swing.action.OpenWalletAction - Executing open of wallet '/Users/XXX/Library/Application Support/MultiBit/XXX.wallet'.
09:38:44.486 [SwingWorker-pool-3-thread-6] DEBUG o.m.v.swing.action.OpenWalletAction - Opening wallet '/Users/XXX/Library/Application Support/MultiBit/XXX.wallet'.
com.google.bitcoin.store.UnreadableWalletException: Transaction did not deserialize completely: 31e9d5ed88db1474e3de92a5a49b2a9ee799f722d8635bf01e6c21ca758dd368 vs a11a4b676eb7bd8d9008a98f70b9bc78a525cb021e05b73737a2b8f569bee7d1
   at org.multibit.store.MultiBitWalletProtobufSerializer.readTransaction(MultiBitWalletProtobufSerializer.java:624)
   at org.multibit.store.MultiBitWalletProtobufSerializer.readWallet(MultiBitWalletProtobufSerializer.java:460)
   at org.multibit.store.MultiBitWalletProtobufSerializer.readWallet(MultiBitWalletProtobufSerializer.java:392)
   at com.google.bitcoin.core.Wallet.loadFromFileStream(Wallet.java:572)
   at org.multibit.file.FileHandler.loadFromFile(FileHandler.java:136)
   at org.multibit.network.MultiBitService.addWalletFromFilename(MultiBitService.java:409)
   at org.multibit.controller.bitcoin.BitcoinController.addWalletFromFilename(BitcoinController.java:137)
   at org.multibit.viewsystem.swing.action.OpenWalletAction$1.doInBackground(OpenWalletAction.java:288)
   at org.multibit.viewsystem.swing.action.OpenWalletAction$1.doInBackground(OpenWalletAction.java:276)
   at javax.swing.SwingWorker$1.call(SwingWorker.java:277)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   at javax.swing.SwingWorker.run(SwingWorker.java:316)
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
   at java.lang.Thread.run(Thread.java:695)

The last time MultiBit was used before, the last log entry reads (and it thus looks like a normal shutdown):

00:31:24.177 [AWT-EventQueue-0] DEBUG o.m.p.b.m.QuitHandlerInvocationHandler - Invoked response method. NativeMethod=handleQuitRequestWith, method args length=2
00:31:24.178 [AWT-EventQueue-0] DEBUG o.m.p.b.m.QuitHandlerInvocationHandler - Building invocation handler. Native QuitEvent -> GenericQuitEvent
00:31:24.179 [AWT-EventQueue-0] DEBUG o.m.p.b.m.QuitHandlerInvocationHandler - Building proxy for generic event
00:31:24.180 [AWT-EventQueue-0] DEBUG o.m.p.b.m.QuitHandlerInvocationHandler - Building response invocation handler. Native QuitResponse -> GenericQuitResponse
00:31:24.181 [AWT-EventQueue-0] DEBUG o.m.p.b.m.QuitHandlerInvocationHandler - Building proxy for generic event
00:31:24.182 [AWT-EventQueue-0] DEBUG o.m.p.b.m.QuitHandlerInvocationHandler - Created event GenericQuitEvent
00:31:24.182 [AWT-EventQueue-0] DEBUG o.m.p.b.m.QuitHandlerInvocationHandler - Invoking DefaultQuitHandler.handleQuitRequestWith(GenericQuitEvent,GenericQuitResponse) 
00:31:24.183 [AWT-EventQueue-0] DEBUG o.m.p.handler.DefaultQuitHandler - Called
00:31:24.183 [AWT-EventQueue-0] DEBUG o.m.p.handler.DefaultQuitHandler - Event class is $Proxy16
00:31:24.183 [AWT-EventQueue-0] DEBUG o.m.p.handler.DefaultQuitHandler - Broadcasting to 1 listener(s)
00:31:24.194 [AWT-EventQueue-0] DEBUG o.m.v.swing.action.ExitAction - Closing Bitcoin network connection...
00:31:24.198 [AWT-EventQueue-0] DEBUG o.m.v.swing.action.ExitAction - PeerGroup is now stopped.
00:31:24.199 [AWT-EventQueue-0] DEBUG o.m.v.swing.action.ExitAction - Closing blockStore. . .
00:31:24.204 [AWT-EventQueue-0] DEBUG o.m.v.swing.action.ExitAction - BlockStore closed successfully.
00:31:24.225 [AWT-EventQueue-0] DEBUG org.multibit.file.FileHandler - Start of secureDelete
00:31:24.355 [AWT-EventQueue-0] DEBUG org.multibit.file.FileHandler - Result of delete of file '/Users/XXX/Library/Application Support/MultiBit/XXX.wallet' was true
00:31:24.355 [AWT-EventQueue-0] DEBUG org.multibit.file.FileHandler - End of secureDelete
00:31:24.355 [AWT-EventQueue-0] DEBUG org.multibit.file.FileHandler - Saving wallet file '/Users/XXX/Library/Application Support/MultiBit/XXX.wallet' ...
00:31:24.357 [AWT-EventQueue-0] DEBUG org.multibit.file.FileHandler - ... done saving wallet file. Wallet file size is 6746 bytes.
00:31:24.357 [AWT-EventQueue-0] DEBUG org.multibit.file.FileHandler - Start of secureDelete
00:31:24.502 [AWT-EventQueue-0] DEBUG org.multibit.file.FileHandler - Result of delete of file '/Users/XXX/Library/Application Support/MultiBit/XXX-data/rolling-backup/XXX-20170501002840.wallet' was true
00:31:24.502 [AWT-EventQueue-0] DEBUG org.multibit.file.FileHandler - End of secureDelete
00:31:24.503 [AWT-EventQueue-0] DEBUG org.multibit.file.FileHandler - rememberFileSizesAndLastModified: Wallet filename /Users/XXX/Library/Application Support/MultiBit/XXX.wallet , walletFileSize 6746 ,walletFileLastModified 1493591484000 ,walletInfoFileSize 377 ,walletInfoFileLastModified 1493591484000
00:31:24.503 [AWT-EventQueue-0] DEBUG o.m.v.swing.action.ExitAction - Saving user preferences ...
00:31:24.505 [AWT-EventQueue-0] DEBUG o.m.v.swing.action.ExitAction - Shutting down Bitcoin URI checker ...
00:31:24.505 [AWT-EventQueue-0] DEBUG o.m.ApplicationInstanceManager - Making request to shut down socket ...