Topic: Corrupted privkey, BTC wallet from 2010, was crossed into a Doge client. (Read 452 times)

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.

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?

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.

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.

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.

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

Have you tried this?

https://btcrecover.readthedocs.io/en/latest/Decrypting_dumping_walletfiles/

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!

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

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.

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 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"
        }

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 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

So how are you getting the info about the keys?

Is the function below (or similar) what's outputting your error messages?

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

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?

This is a month going. I know there is BTC in my old wallet. Long story short. Mined in 2010, forgot about it. Loaded wallet.dat into DOGE client in 2013 on accident. Noticed pretty quick and pulled it back out but the damage has been done. There are 203 keys reporting with 1 unknown when sending zapwallettxes in bitcoind. Pywallet, bincoind dumpwallet and various other key dumping method are only dumping 213 keys. You can see the code break in the dump for the addresses. A few of the wallet dumps give a script 7 error. Salvage wallet just wasted my time. It may be possible the original BTC wallet was encrypted, and Doge encrypted it again. Or the wallet had the primary key dumped aside and coded. I have my primary password to unlock. I was also wondering it I could remove the encryption without a dump if it would produce at least a encrypted key string. Too many countless nights here. I am about to call it quits for another few years. Below is a output of some of the data.

Wallet data not recognized: Bdict({u'__type__': 'flags', u'__value__': '\x00\x00\x00\x00\x00\x00\x00\x00', u'__key__': '\x05flags'})

Wallet data not recognized: Bdict({u'__ty__': 'cscript', u'__value__':
'\x16\x00\x14\xfd\x16,\xd44J\x1d\x90\x82$\xc0\xadQ*\x14S\**\***** ', u'__key__': '\x07cscript\x1cg\xa7\xc4\x8d\***\***\xc2\x0b\xa7\xaf\***\xef;\xd8*K\x*1'})


Wallet data not recognized: Bdict({u'__type__': 'cscript', u'__value__': '\x16\x00\x14\***\xb7\x9a\xa0\xd9\xe1Br\xb4x\x89\***\xb6\xd5\xfb&\x18\t\****', u'__key__': '\x07cscript\xf5\x90\x1a^\x89\***\x92\xbd\x19*\xaa\x07\xcf;_\xfbI\x1e\****'})

Wallet data not recognized: Bdict({u'__type__': 'purpose', u'__value__': '\x07receive', u'__key__': '\x07purpose*bc1ql5tze4p5fgwepq3yczk4z2s52wrv2j6jvg998j'})
Wallet data not recognized: Bdict({u'__type__': 'purpose', u'__value__': '\x07receive', u'__key__': '\x07purpose*bc1quxme4gxeu9p89drc38qtd40mycvqncnxr3dd4p'})
ERROR parsing wallet.dat, type setting
key data: settingaddrIncoming
key data in hex: 0773657474696e670c61646472496e636f6d*****
value data in hex: f0eb0000