... had emailed themself an email in September of 2013 titled "key" with the body of the email containing a string of 64 numbers and lowercase letters beginning with 9.
Is this 64 characters long string composed of only the number 0-9 and letter a-f?...
Yes, numbers 0-9 and letters a-f.
I downloaded the bitaddress.org script on an old laptop and went offline. I entered my spouse's key in the wallet details tab. I downloaded electrum on my other laptop and entered the public key generated from bitaddress.org and the 51-digit WIF key generated by bitaddress.org. I see no balance or history on the bitcoin address...
When you convert the 64 chars hexadecimal string to WIF private keys, you have two options: an uncompressed and a compressed key. The uncompressed WIF starts with a 5... and the compressed WIF with K... or L...
It's enough to import both private keys into Electrum and maybe check different Electrum servers if all do sync fine.
Are you saying to try both WIF keys with both public addresses on multiple servers? Is Electrum able to discern all that whilst offline? And if not, isn't entering the private keys while electrum is online compromising their security? And is doing all this necessary if mempool.space already reveals no balance or history on these public addresses (other than what I have just transferred in)?
I would check the resulting public addresses with at least two different block explorers, mempool.space seems very reliable to me, even when address histories are huge.
I tried both on mempool.space and the compressed address showed the 10k sats but no other balance or transaction history. The uncompressed indicated no such address. Is this not enough to confirm that there is indeed no bitcoin at these addresses? In which case, the only other hope it is an alt coin of some sort?
My friend points out that my spouse had likely been playing with the idea of bitcoin but never got to the point of buying any.
If the hex string converted directly to WIF private keys doesn't hold funds, you could also try to hash the hex string (as string and as binary data) with SHA256 (once, twice, multiple times). This yields you more samples of 256 bits chunks to test if converted to private keys with funds.
Now that I've confirmed the funds I've transferred are indeed at the public address, is it still necessary to try hashing the hex string multiple times? Would this somehow reveal something mempool.space hadn't? Or are you saying there could be a different public address matching my private key than what bitaddress.org has calculated?
Another idea:
As BIP32 was published in 2012 and BIP39 in September 2013 the hex string could also be the starting entropy for such a derivation. Though a bit unlikely to already be applicable to BIP-39 initial entropy.
Again, is it worthwhile exploring this possibility if mempool.space shows no balance or history at the public addresses? (Perhaps I'm missing something... I'd be happy to, of course, if there is still some possibility.)
Thanks again for all your advice.
Show Posts
