Bitcoin Forum

Other => Beginners & Help => Topic started by: underworld07 on September 16, 2012, 06:53:14 PM



Title: wallet.dat corrupted?
Post by: underworld07 on September 16, 2012, 06:53:14 PM
I think have managed to corrupt my wallet.dat. I was initially running coderr's patched client on linux (ubuntu 12.04), but the most recent version was 0.5.3 (there is no updated version of the patched version). I was running bitcoind (as opposed to bitcoinqt). I received some bitcoins (almost 7 of them) at the address that was displayed by bitcoind in the javascript rpc client, before all of the blockchains were downloaded.

As more of the blockchains started downloading, I noticed that bitcoind started crashing. I figured it might be a software version issue, and upgraded to bitcoin 0.6.3. This version kept crashing so I backed up my wallet and rolled back to a fresh install of 0.5.3 on a separate (windows) machine, and tried to use the new install with the old wallet files (original backup and latest version) after the blockchain was fully downloaded. The client would crash saying the wallet was corrupted, or would load a different bitcoin address. I also tried versions of the wallet that had been run through bitcointools' fixwallet.py but could not get rid of the corruption.

I have also tried pywallet to get a text file with the keys. This produces output in a format as described in the forums, but the private keys produced by pywallet don't actually match the address (I tried entering the resulting output address:seckey pair into electrum, and it said they were incorrect). I even tried pairing the address with every seckey from the pywallet output, one by one, and electrum rejected all of the pairs. I can only assume that changing the version of bitcoin, and/or switching from the coderr "enhanced anonymity" version of bitcoin to the official client corrupted my wallet.dat.

It is remotely possible that the wallet.dat is not actually corrupted, but is just consistent with the old 0.5.3 coderr version of the client (which incidentally cannot be used to export private keys - that was only introduced in 0.6) and the new version of the client (and the older windows client) just see it as different, and assume it's corrupted (and in the case of pywallet, maybe it misinterprets it). This would be consistent with the fact that I have also tried starting a new install of coderr's 0.5.3 on linux with a newly generated wallet.dat, and I still run into the issue that at a certain point, it keeps crashing as it tries to download the blockchain.

However, I'm at my wit's end, and would greatly appreciate help from a "Hero member" as I don't think there's much more I can do on my own now, so I will have to trust someone with my wallet.dat.

Please let me know if you would be willing to help

Many thanks!


Title: Re: wallet.dat corrupted?
Post by: mufa23 on September 16, 2012, 07:36:05 PM
Just because someone posts here a lot, doesn't make them trust worthy. But if you have no other option, I guess it really doesn't matter.

If you send me a copy, I'll load it onto my second computer and try to run it.

EDIT: Actually, I have to reinstall the blockchain on my second PC. So if you wanted my help, it would take awhile.


Title: Re: wallet.dat corrupted?
Post by: underworld07 on September 16, 2012, 08:46:08 PM
Thanks very much for your offer to help - I'm PMing you now


Title: Re: wallet.dat corrupted?
Post by: DeathAndTaxes on September 16, 2012, 08:57:31 PM
Quote
but the private keys produced by pywallet don't actually match the address

what do you mean the private keys don't match the address.

take one of the private keys and import it into a new client.  The two simplest options would be blockchain.info or MtGox account. 
Does it import?
What address is listed?

Assumming the private keys are valid you should be able to import them into new wallet from the lastest version of bitcoin-qt or bitcoind.


Title: Re: wallet.dat corrupted?
Post by: underworld07 on September 16, 2012, 09:32:54 PM
Thanks for your reply Deathandtaxes

Based on the output from pywallet, I tried importing the private key that corresponded to the right address into blockchain.info and it imported, but gave a different address. So unfortunately, while they are valid, they don't correspond to the addresses that they appear to correspond to.
    "defaultkey": "1HxxxxxYcm",  [this is 34 characters long in reality]
    "keys": [
        {
[lots and lots of keys]
  "addr": "1HxxxxxYcm",  [this is 34 characters long in reality]
            "hexsec": "xxxxxxxxxxxxxxxxxxxxxxxxxx", [this is very long]
            "label": "",
            "sec": "5Kxxxxxxek" [this is 51 characters long in reality]

[lots more keys]
[some other stuff]

When I enter 5Kxxxek as the secret key into blockchain.info, I get a new address that doesn't end with Ycm

Also, the electrum client allows you to import a keypair in plain text in the format address:key. I tried every combination of 1HxxxxxYcm and the sec entry, e.g.
1HxxxxxYcm:5Kxxxxxxek
1HxxxxxYcm:[other versions of 5Kxxxxxxek paired with other addresses]

in all of those, the electrum client said that the address didn't match the private key


Title: Re: wallet.dat corrupted?
Post by: Stephen Gornick on September 16, 2012, 09:42:23 PM
I have also tried pywallet to get a text file with the keys. This produces output in a format as described in the forums, but the private keys produced by pywallet don't actually match the address

Others have reported that same problem with pywallet:

 - http://bitcoin.stackexchange.com/questions/4428


Title: Re: wallet.dat corrupted?
Post by: DeathAndTaxes on September 16, 2012, 09:44:07 PM
Does the address produced correspond to any address in your wallet?

If so it may mean the private keys are still valid.  You could export them all and import them using RPC (probably by batch) into a new wallet.dat running on a new client.


Title: Re: wallet.dat corrupted?
Post by: mufa23 on September 16, 2012, 10:03:03 PM
Got it working. I PM'd you.


Title: Re: wallet.dat corrupted?
Post by: underworld07 on September 17, 2012, 09:44:52 PM
mufa23, you're my hero

For everyone else's benefit - all of the bitcoins from my corrupted wallet were transferred by mufa23 to a new wallet I specified, completely untouched.

mufa23 - if you would be able to provide any color on how you fixed this, I'm sure it would be greatly appreciated by the community. My old wallet is completely redundant now, so feel free to post extracts from it (e.g. output from pywallet) if it helps explain (of course from my perspective you have done enough, but I'm sure others would greatly appreciate it). As per the PM I sent you, I'd love to send you a small token to express my gratitude.

Thanks again!


Title: Re: wallet.dat corrupted?
Post by: underworld07 on September 17, 2012, 09:57:33 PM
Deathandtaxes - in answer to your question, I entered the private key that corresponded to the address ending in Ycm from the pywallet output (i.e. the private key ending in ek I mentioned previously) into blockchain.info. That resulted in an address ending in UyHf, which did not correspond to any address in the pywallet output. So the secret keys in the pywallet output, while valid (in terms of length etc), don't seem to correspond to the addresses in that file at all - I say this because:

1) I picked an address - the Ycm one - and tried importing it with each of the secret keys in that file and electrum client indicated that none of the combinations were valid, and

2) I picked a secret key - the one that appeared to correspond the Ycm address and that ended in ek, and generated the corresponding address in blockchain.info, and it didn't correspond to any of the addresses in the output of pywallet)

I'm not sure whether this is a version incompatibility between pywallet and older versions of the client software, or a bug in pywallet, or some other issue (genuine corruption in the wallet.dat), but it is quite bizarre!

Stephen Gornick - that's an interesting link and describes what seems to be exactly the same problem. If anyone could shed any light on why this occurs (or how it can be fixed) I'm sure this could be of huge benefit to others.


Title: Re: wallet.dat corrupted?
Post by: mufa23 on September 17, 2012, 11:47:34 PM
mufa23 - if you would be able to provide any color on how you fixed this, I'm sure it would be greatly appreciated by the community.
When you PM'd me, you provide me with two downloads for the "new wallet" and the "old wallet". I was only able to download the first one (new wallet) because they website didn't like me downloading one then one download that day. I opened up the wallet, and skimmed through the code for a few seconds. I didn't notice anything out of the ordinary, but I only spent a few seconds looking.

-I installed a fresh copy of Bitcoin-qt 0.6.3 on my secondary windows computer (.exe, not the .zip).
-Started it up
-Settings>Options>Detach database at shutdown
-Turned off Bitcoin-qt
-Deleted blockchain that had started to download
-Deleted my wallet that generated, and replaced with underworld's.
-I detached the database on my primary computer, turned it off, and backed up the blockchain (blk0001.dat, blk0002.dat, and blkindex.dat)
-Loaded those files onto second computer, then started backup bitcoin-qt on the second computer

The client crashed a couple of times while trying to start, and to had to forcefully kill the process twice. The UI splashscreen would crash everytime I tried to start it. It did it's normal "Loading block index" or whatever, and I did notice that it said something about "Rescanning...". Most the of the time though, it would just glitch and all I could see was a whitebox in the middle of my desktop. Anyway, after about 20 minutes of this, I finally got the client to start and load the wallet. I didn't shut it off until underworld gave me a new address to send to. I figured if I shut it down, I might not get so lucky and lose those coins. A couple hours after I got it working, underworld PM'd me an address to send the coins to, and I sent them. As of right now, I can start the client up, and it will load the address. I assume the client fixed the issue itself.

A clean installation seemed to do the trick. Not really sure how/why though. Glad it worked though. All-in-all, I spent a little over an hour while doing some homework.