Hey everyone,
I’ve been going through an old hard drive trying to find some lost bitcoin after taking a 3-year break from this.
Finally got PyWallet to work on Windows, but at the end of the scan, it shows that it found 9 potential unencrypted keys.
However, when I try to import them, I hit a runtime error. Here’s the output:
Importing key 1/1:
Traceback (most recent call last):
File "pywallet.py", line 4907, in <module>
importprivkey(dB, sec, "recovered: %s"%sec, None, True)
File "pywallet.py", line 2625, in importprivkey
pkey = EC_KEY (str_to_long(sec.decode('hex')))
File "pywallet.py" line 1059, in __init__
self.pubkey = Public_key( generator, generator * secret )
File "pywallet.py", line 1003, in __init__
raise RuntimeError, "generator point has x or y out of range"
RuntimeError : generator has x or y out of range.
Also, when I run a dump wallet on the recovered wallet, the export text file doesn’t show any keys. I think there’s something wrong after the recovery process because none of the 9 potential keys are making it into the file. Any help would be greatly appreciated.
Thanks,
Dan
Not-too-important note: That line means that it tried to import a single key, just one.
Otherwise, if it tried to import all 9 keys, it should be "Importing key 1/9" ~ "Importing key 9/9".
The error doesn't look like related to the "found keys" but rather an issue with your pywallet and Windows setup since it involves an invalid G.
Ref: https://github.com/jackjack-jj/pywallet/blob/811c6bee054657783e7c2683bdfded5700241e17/pywallet.py#L1218-L1219
Which version of Python2.7.x are you using? The final version is v2.7.18.
Which/Who's Pywallet fork are you using?
Can you try another --recov_device containing a working legacy wallet.dat to see if it will proceed to import intact keys?
Thanks Nc50lc
I did think it strange importing 1/1 rather than 1/9 any ideas why it is only trying a single import if 9 possibles are found?
Python version 2.7.18 build from April 20 2020
The PyWallet I think is mikeborghi's version I downloaded a few types whilst trying to get it working with dependencies etc. It might be the hardcorepawn/PyWallet/blob/master/PyWallet.py actually looking at the timestamp.
Interestingly if it does not find keys in a recover it appears to create a wallet with no runtime issues.
Will try put through a dummy wallet dump with keys and see what happens all those addresses I know to be empty.
Thanks for the assistance, it's appreciated.
You don't try your recovery attempts on your original storage media, do you? It's important to only work on forensic copies or the original to avoid any possible and detrimental alteration or the original filysystem by any recovery tool you use.
That's actually a very good advise. Always verify your recovery tool(s) are capable to successfully do the job, otherwise how could you know that your recovery attempts will lead to something useful.
Have you tried other versions of PyWallet? Why exactly have you chosen your particular fork?
Try jackjack's version where mikeborghi's version is based of: https://bitcointalk.org/index.php?topic=34028.0
It has more recent commits than the said fork.
I've tested that version but failed to reproduce the runtime error.
But it somehow failed to import the seven out of nine keys that jackjack's version managed to import.
Logs (mikeborghi/pywallet):
Logs (jackjack-jj/pywallet):
It's probably because it found a correct or similar header but the next bits aren't enough to be a valid private key.