Lost privkey, BTC wallet from 2010 got mixed up with a Doge client

Been struggling with this for a month now. I know there’s BTC chilling in my old wallet. To keep it brief, I mined some coins back in 2010 and totally forgot about it. Then in 2013, I accidentally loaded my wallet.dat into the DOGE client. Caught the mistake pretty quickly and extracted it again but the damage was already done. Now I'm seeing 203 keys with 1 unknown when trying to send zapwallettxes using bitcoind. Tried using Pywallet and bincoind to dump the wallet, but they're only giving me 213 keys. You can actually see the code messing up in the dump for the addresses. A few wallet dumps throw a script 7 error my way. Salvage wallet just ended up wasting my time. I’m starting to think maybe the original BTC wallet was encrypted, and the Doge client added another layer of encryption. Or, the primary key was dumped separately and messed up somehow. I do have my main password to unlock it. Was curious if there’s a way to remove the encryption without doing a dump, maybe just to get at least an encrypted key string. It’s been too many sleepless nights dealing with this. Honestly thinking about giving up for a few years again. Below is some of the data output I got.

Can you get into a bit more detail about what happened when you loaded the wallet into DOGE, how you loaded it and at what point you realized your mistake and quit/killed the DOGE client if you can remember?

It was maybe 10-15 minutes. I cannot remember details of it it was encrypted or if I encrypted it on start up. Its encrypted now with a known password. Clean load. Still cleanly loads in BTC client with invalid Meta data from 2 doge deposits. Probably were mining deposits from BTC client 0.3

So how are you getting the info about the keys? Is the function below (or similar) what's outputting your error messages?

I partitioned a usb to 50 megs, Clean format, Copied wallet.dat into it and ran something like this, 213 keys dumped with --recover, but there are 213 with 1 unknown, According to bitcoind -zapwallettxes=1 python2.7 pywallet.py --recover --recov_device=/path/to/wallet.dat --recov_size 50Mio --recov_outputdir=/tm This output is from jackrabbit pywallet --dumpwallet

The initial error you were getting seems to be a known issue with the updated version of PyWallet (jackjack is busy updating it). You would need to try an older version of Pywallet... or wait for jackjack to resolve the issue. I have a copy of the older version here: https://github.com/HardCorePawn/pywallet NOTE: It requires Python 2.7... it will not run with Python 3. As for the private keys, it should not have "compressed" any keys... As you've discovered, a private key can be converted to compressed or uncompressed public keys, which then leads to different addresses being generated. However, the underlying (hex) private key will remained unchanged. If you are able to load the wallet into Bitcoin Core, does the dumpwallet command in Bitcoin Core work? What WIF format keys are you getting? Otherwise, the output from PyWallet's dumpwallet should have given you the raw hex encoded private keys that you should be able to use to generate compressed/uncompressed public keys and WIF's etc.

I know its been a while, I kind of took a break from this. Anyways I had tired https://github.com/HardCorePawn/pywallet and I still get a "bdict error" End of the data says "_____u_key " from bdict error. Also there is alot of data before it. So I suspect the wallet from BTC core v0.2 generated 1 key like it should. That wallet was then loaded into a LTC client in 2013, Data was corrupted, I thought it was doge, but found it appears to be a LTC client that was actually used. I tried this pywallet https://github.com/mikeborghi/pywallet and this one does not give me a error. However there are 202 keys found, same amount as every time. Here where it gets interesting. The Keypool data for the very last key is different then all the other keys in the wallet when dumped with dbdump_4.8 Also when dumped with pywallet the Ntime value is different for the last key. Ill attach a snipped of public key data from the dump. 20% for whomever could help.         {             "addr": "1N1SChDzQ1EyKm3nb5u6wGRyzhepYdNwEZ",             "n": 97,             "nTime": 1386907297,             "nVersion": 80501,             "public_key_hex": "03e54218920b5a65f8a719b6c3a8688ba372edacd357cd972903f1739d4423e8cc"         },         {             "addr": "19vH287DnfvTCGn32n57tak3PLMty3n2Uz",             "n": 98,             "nTime": 1386907297,             "nVersion": 80501,             "public_key_hex": "029d8825c8980fecce7583630164af7a4f7530c5602c4df645d9e29ba7c352e2ab"         },         {             "addr": "1DymDmrQi3VhQzAY7Z64pCBMzP5ZnLPxcE",             "n": 99,             "nTime": 1386907297,             "nVersion": 80501,             "public_key_hex": "039e92ce90bacbe769968c7aa103b4a90a1e49519af9a871a826544afba048acd3"         },         {             "addr": "16JBptL2TuLDUjRcU5GGRBbj3XTfoZq3Hw",             "n": 100,             "nTime": 1386907297,             "nVersion": 80501,             "public_key_hex": "03e9092f11b0d45ce1e843c37f03f930f0c5f133ebc3d898a076464515f49fed93"         },         {             "addr": "1PbyL7dJsjAaMvPWx85UW7SVtuoh6qRDna",             "n": 101,             "nTime": 1386914343,             "nVersion": 80501,             "public_key_hex": "03f8f3bbe1cb60b4c77c031d39ec94d6babfd60930912256b14346e7a0e763ac6b"         }

Did they use compressed public keys back in 2010? Not sure why your keys are compressed, also I'm not seeing any balance on those addresses, one has to wonder what you are going to share 20% of, when there is nothing specified, though if the amount you are missing is more than 1000 bitcoins, then 20% would be 200, and if you have a public key needing to find it's private key, show it here.

I do not have a suspect Public key. Also the suspected ec key converted to uncompressed public key has no value. My request for help relates to any possible means of recovery of the data in the wallet. 20 percent of what I have, which may be nothing. But everyone will notice if a legacy genesis Era wallet moves funds and I will keep my word.

My thoughts.. looking at this address, addr": "1N1SChDzQ1EyKm3nb5u6wGRyzhepYdNwEZ", It has not transacted. So, the program you are using is processing the wallet with your wallet passphrase, which is deriving a master key which in turn is decrypting all the Ckeys in the wallet producing the compressed addresses. (I don't believe compressed addresses were about in 2010?) There are scripts about to convert compressed addresses to uncompressed so you could check all 200ish uncompressed addresses to see which ones have a balance. Again there are scripts to automate this. You can then dump the wallet to get all the Ckeys. With the Ckey of the address with the balance and the passphrase master key,  it would be possible to decrypt that individual private key even if the wallet was corrupt. I do have scripts that can do this which are not public but I am sure there are others out there.. Good luck

All EC keys have been converted and checked uncompressed. No value. Unless the data is in the wallet and not dumped with the scripts. Compressed keys were not used back then you are correct. I am willing to try whatever scripts you have. Thank you!

Have you tried this? https://btcrecover.readthedocs.io/en/latest/Decrypting_dumping_walletfiles/

It's not about the "money" or your ability to keep your promise, the problem is with the balance of your wallet, if there is no balance, if you can't provide an actual address with balance, then you might as well be seen as someone trying to waste our time( other's time).  So once again, are you going to show us an address with balance or should we imagine about your imaginary coins? And I have a talking cat, not showing it to public, only if you come home. Lol

How about the "recovered_wallet.dat" in your --recov-device? Was it the one you loaded in Bitcoin Core when you used --zapwallettxes? (now removed in Core) If so, the "..contains the 213 recovered keys" shown in the command line are the actual number of private keys imported to the 'restored_wallet.dat'. Whatever --zapwallettxes shown may be from an issue with the recovered_wallet.dat file, not that it included one extra corrupted key during import. If not, have you tried to finish rescanning your blockchain while that "recovered_wallet.dat" is loaded? Suggesting a manual search with hex dump may be futile since --recov already did the same because it's basically how it searched the --recov_device.

Those are compressed public keys. It could even be they were created by your Litecoin client. I checked the LTC balances using Secretscan.org, and it's all empty.

Gave it a shot, Btcrecover does not support dumping legacy core wallets. At least that is what the script told me once I had it up.

Could you please share the specific error message? I seem to remember that this worked in older versions of BTCRecovery. So I would be surprised if the feature has been removed. You could otherwise contact support with the specific error message via github-issues: https://github.com/3rdIteration/btcrecover/issues You might get some more hints here what else you could try?

The ntime version of the last key is not very far off from the rest - Fri Dec 13 2013 04:01:37 vs Fri Dec 13 2013 05:59:03, so only a span of two hours. All of your bitcoins were in one address, I'm going to assume? So we know: - it's a legacy address (duh) - it's uncompressed - it could possibly be the last key - but then why would Litecoin place the address with balance at the back of the keypool (if that was even used back in 2013)? I'm pretty sure there was no keypool being used in Bitcoin Core in 2010, as you could only create addresses using getnewaddress and stuff like that, and wallet creation apart from default wallet.dat was certainly not possible from the RPC back then.