Entering Passphrase crashes bitcoin client #711

On 0.4 error shows EXCEPTION: 9key_error
CKey::SetSecret() : secret must be 32 bytes
bitcoin in CMyApp::OnExceptionInMainLoop()

On 0.5 no error just quits

Does this happen on a specific passphrase, or no matter what you enter?

What platform?

I am on the MAC OSX 10.7.2 LION

The passphrase seem to work if I create a new bitcoin folder in version 0.4/0.5

Problem is the original dat file was created since early client 0.3

Durning one of the migration to each version I was having a bug when I get a new transaction, the client would automatically generate a new bitcoin address by it's own (I believe it was client 0.4 before I input passphrase). This was fixed after I input passphrase.

I still have the files from 0.4 after I input the passphrase, this seems to be the point where everything started. I get the EXCEPTION error still when i load up the files.

Hmm, it seems you have one (or more) private key(s) that are somehow corrupted. I would recommend moving any and all coins in the wallet to a fresh wallet. If you can provide more info on when/how corruption might have happened and on exactly which versions, it would be appreciated.

My wallet file is encrypted is there anyway to decrypt the file so I can move out all my bitcoins? I can't use the client since every time I enter in the right passphrase the client crashes.

Ah, well now thats a problem...do you not have a wallet file backup?

I've looked a bit at the source, and it seems this error is thrown when your wallet contains an invalid secret key. It discovers this only after you enter the passphrase as the secret keys are encrypted.

As BlueMatt says, this is probably a result of wallet corruption. Fixing this issue will require a special-purpose script, or (easier) restoring a backup...

I really wish I had a backup pre-passphrase wallet.dat file. It didn't dawn on me till I tried to use some of the coins. I really want to recover those coins since it took me like 7 months of work on a slow machine.

I'll see if I can write a branch to work around that error sometime in the next couple days if I have time

I appreciate all the help I can get. I did a google search for my error and it seems like there was one other instance of the same error.

I would donate to the cause, but I would need to wait till I can get some BT on my new wallet file.

Heh, well I havent looked at that particular code in a while, but (IIRC) it shouldnt be too hard to just ignore the error and keep loading the wallet to avoid the client crashing so you can get some of your coins back...

I think "ignoring the error" isn't good enough. If my wallet is corrupt, then I really want to know about it; maybe my hard disk is going bad and it is time to buy a new machine.

But just throwing an uncaught exception as bitcoin does now is definitely the WRONG thing to do. Lets brainstorm a little on the best way to fix it:

First, it seems to me telling the user should be told that their wallet file is corrupted. Then maybe: give the user a choice: exit Bitcoin (they can restore from a good backup), or try to recover.

I'd like to see a "Try to Recover" that took a "first, do no harm" approach and did something like:

• Closed/renamed the existing wallet.dat
• Rewrote a new wallet.dat, skipping all 'tx' records and any un-serializable or un-decryptable records
• Re-scanned to recreate transaction history
• Gave the user a report on whether or not any keys could not be recovered

... although maybe all that would be better implemented as a separate tool or "re-run bitcoin with the -fixwallet switch."

For a quick-and-dirty fix for yellowcoin, maybe a pair of new command-line args: -fixwallet=fixedwallet.dat -walletpassphrase=foo ... that did a read/unencrypt/re-encrypt/write and skipped anything that didn't unserialize or decrypt properly...

And "we" should generate some nicely corrupted testnet-in-a-box wallets to make sure it works... (bitcointools should be handy for that).

Yes, switching from "fatal errors" to "ignore errors" is not a good thing. I think BlueMatt was only proposing to do that as a fixup for yellowcoin's specific case.

The first step for proper error handling would be to restore the dialog box when a fatal exception occurs, instead of silently exiting to the console (so catch uncaught exceptions, maybe log them somewhere as well).

A full recovery function would be even better, but is also more work (and very hard to test).

@laanwj exactly, I was proposing writing a patch specific to this case, not modifying bitcoin to ignore errors in general.

I like the idea of the -fixwallet switch. Sometime things happen and you never know if you had backed up a corrupt file when the program itself works fine with it. If I ever get my coins out of the wallet I can send you guys the corrupt wallet.dat file so you can check out what's going on with it.

btw is there a general BTC address I can send some coins to support all the help?

Thanks!!

Try building off master + this commit: https://github.com/TheBlueMatt/bitcoin/commit/06dee4caf1410181b2f6097b5b3311300659c185 it is absolutely not for use, but if you have coins on the right keys, you might be able to send them to a new wallet (no guarantees it wont crash on send). Sorry, I dont have an osx box to build a binary for you.

There is no address for supporting all the developers, though most of them have addresses in their forum sigs (gavin asks that people donate to the faucet instead, which is always a good idea to help new people try bitcoin - freebitcoins.appspot.com )

i am using mac osx...how do I compile the file with the added code??? I quit programming since college lol

(edit) I can switch to windows if anything.... I assume I copy the QT folder from the branch and compile the main.cpp file with the added code?

If you are setup to build on osx (doc/build-osx.txt might help if you arent) you can grab a zip of that revision at https://github.com/TheBlueMatt/bitcoin/zipball/06dee4caf1410181b2f6097b5b3311300659c185 which you can build from, otherwise you'll have to find someone to build for you (maybe gavin would be willing to when hes back around after the holidays)

Thank's i'll give it a try... After many years I end up programming again haha

If its easier, I can whip up a windows or linux build, I just dont have a mac conveniently available atm...

if you can do windows that'll be great!! Otherwise i will have to wait for xcode for the mac to finish downloading. 1.7gig download is going to take a while.

When the build at http://jenkins.bluematt.me/job/Bitcoin-Testing-Build/16/console is done, you should be able to grab the modified bitcoin-qt.exe at http://jenkins.bluematt.me/job/Bitcoin-Testing-Build/ws/

Oh, and dont dare sending any amount less than the full wallet balance while using this modified version, it might mean your coins go to an address which people actively watch and swipe coins form when they appear (privkey 00000....)

ok so I tried running the program with the modified exe. I tried entering the password and it's telling me it's wrong. I am sure I used the same one that crashes the program before.

Also notice the file size is different from the release version. About 273kb smaller then original build.... is that normal?? I would think the file would be bigger since you added a few lines.

Oops, missed that, new version uploaded, just wait for its build. Filesize: meh, its being built with a different set of libs on a different machine filesize is gonna change, the build is fine.

http://jenkins.bluematt.me/job/Bitcoin-Testing-Build/17/console

ok so now it sort of works. New error: Transaction creation failed

Happens after i hit the sent button.

Thought so, maybe try (after backing up the wallet) stripping transactions see https://bitcointalk.org/index.php?topic=11331.0 and opening bitcoin (the modified version) with -rescan.

Oh, actually that rescan wont work...well Im not sure how it could be easily done...might be easier to at least check how corrupted the wallet is first, Ill whip something up after a couple days...

Hey thanks again! I went a head and mess around with the revision fixwallet.py you posted on the last site you directed me to.

With the unmodified version of bitcointools i can see pubkey ..... encrypted ....prikey..... With the modified version I get [Skipping item of type ckey](the ones with the --notxes and additional switches)

This makes me think that I would need to first remove the decryption from the wallet file in order to send out my coins. The unmodified version of the bitcointools seem to see the wallet just fine. I think it's just the matter of using the password I have and decrypt it back to a non-passphrase state.

Worse case scenario, i'll just have to send you my wallet file.

Give it a try again.

you want me to grab the new fixwallet.py & wallet.py files at https://github.com/TheBlueMatt/bitcointools/commit/e48469a65a4ff1f92ceaf5c0bc9ac1eaf9044c11

right?

i tried running it again and got this error:

C:\Python27\bitcointools>dbdump.py --wallet Traceback (most recent call last): File "C:\Python27\bitcointools\dbdump.py", line 10, in <module> from wallet import dump_wallet, dump_accounts File "C:\Python27\bitcointools\wallet.py", line 4 <!DOCTYPE html> ^ SyntaxError: invalid syntax

The tip of the morefix chain is 5c359a2f0f5f0df841aba275910f81f92301362b, but that shouldnt have caused the error there, there is no <!DOCTYPE html> in wallet.py afaict...

The zipball you want is at https://github.com/TheBlueMatt/bitcointools/zipball/morefix

ok i unzipped the file and ran the dump and fix --notxes command. Got a bunch of [Skipping item of type tx] then ran a rescan...no dice...

I tried with a --nosettings but that caused the client to not even load the wallet. I would try the --nopubkeys command but I am not sure if that will even help. Would you like me to send the wallet.dat file to you? Maybe you will have better luck.

If you feel like it, go right ahead (bitcoin@bluematt.me) ...Im not so sure about what is doable at this point...

ok sent! should be from a gmail account. ty again!

Closing this bug because we cannot reproduce it.

Should be fixed by #1039.