64-digit Hex Key Beginning with 9 -- Does Not Belong to BTC Address?

[hugyour]

Before I fully give up, I want to confirm my process to be sure this key doesn't belong to a bitcoin wallet.

My now-deceased spouse 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. It was at the same time my spouse was moving a lot of money around due to a change in employment and income. Buying bitcoin is something my spouse would definitely have been inclined to do, though I don't know the method by which they would have; they weren't particularly tech-savvy but were ingenuitive.

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.

I sent .0001 btc to both the compressed and uncompressed bitcoin addresses (as generated by bitaddress.org after entering the 64-digit key) from Coinbase and confirmed these transactions on btcscan.org with no other transaction history showing for those addresses.  

From the steps I've taken thus far, is it fair to assume the key in my spouse's email does not in fact belong to a bitcoin wallet? I think I understand that these sorts of keys can be used for other purposes, not just crypto/blockchain.

Thank you for your time. I will be mostly away from my computer today but will reply intermittently.

[Mia Chloe]

In a situation like this if you don't intend to go too tech savvy, I'll suggest that you just pick up that private key and load it up in something like unstoppable wallet that accepts both altcoins and bitcoin. Now here's the catch; unstoppable wallet will run the key and search for a valid checksum for it if it is bitcoin or not But you have to be very careful and make sure that your connection is safe so you don't lose your funds.

You seem to have made mention of sending some funds to the wallet well how were you able to get the wallet address if you haven't loaded up the wallet. That's because it's difficult to get wallets that can send funds to a public address.

If you loaded it on Electrum and no wallet pooped up then it's definitely not a bitcoin wallet. Having 9 as the. First character means it could be any altcoin probably Ethereum doge or BCH. since a typical compressed bitcoin key starts with either "5" or "6"

[hugyour]

In a situation like this if you don't intend to go too tech savvy, I'll suggest that you just pick up that private key and load it up in something like unstoppable wallet that accepts both altcoins and bitcoin. Now here's the catch; unstoppable wallet will run the key and search for a valid checksum for it if it is bitcoin or not But you have to be very careful and make sure that your connection is safe so you don't lose your funds.]

So, you are advising that it is okay to enter the private key into unstoppable wallet with an internet connection as long as the connection is secure.

You seem to have made mention of sending some funds to the wallet well how were you able to get the wallet address if you haven't loaded up the wallet. That's because it's difficult to get wallets that can send funds to a public address.

I downloaded the bitaddress.org script (I think it's a github script), put my laptop offline, and entered the private key as a hex key in the bitaddress.org wallet tab and it generated the WIF key, compressed and uncompressed private keys, and other variations on the private key. I read this process suggested at a few places which is why I had hoped it would work. I understand that you can find a public key if you have the private key but not in reverse.

I did not find any wallet on their hard drive backup and tried logging into some exchanges that were around then and now but haven't found anything promising. It's not possible that my spouse had purchased bitcoin in some way and received a private key without having set up an actual wallet?

If you loaded it on Electrum and no wallet pooped up then it's definitely not a bitcoin wallet. Having 9 as the. First character means it could be any altcoin probably Ethereum doge or BCH. since a typical compressed bitcoin key starts with either "5" or "6"

Yes, I believe i entered it as a wallet or tried to sweep from it but it said there was no history of any transactions or that it had a zero balance. I can doublecheck.

Thanks again for all your advice.

[Cricktor]

... 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? If yes, it's pretty safe to assume it's hexadecimal and represents 256 bits of "something".

If you exposed the string to your old laptop while it was offline, it's not good for the safety of the string if this old laptop goes online some time later again, unless you completely wiped the mass storage. As long as you don't know what this string of symbols represents, security of it should be taken seriously.

A safer procedure would be to boot a live Linux on the old laptop that only runs in RAM and doesn't store anything persistantly. Of course, keep it offline. When you turn of such a live Linux, RAM gets wiped or forgets its content and nothing is left on the device.

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.

I sent .0001 btc to both the compressed and uncompressed bitcoin addresses (as generated by bitaddress.org after entering the 64-digit key) from Coinbase and confirmed these transactions on btcscan.org with no other transaction history showing for those addresses.  

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. Sending 10k Sats seems unnecessary to me, but you can transfer the Sats back to your wallet, minus fees, of course. 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.

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.

Do not disclose anything if someone asks you to tell them what your spouse saved as "key". BTW, saving such details per email is a quite unsafe "backup" method. Thou' shall not expose your keys publicly.

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.

I'm just brain-storming...

You seem to have made mention of sending some funds to the wallet well how were you able to get the wallet address if you haven't loaded up the wallet. That's because it's difficult to get wallets that can send funds to a public address.

OP converted the likely hexadecimal string to a private key in WIF representation using the bitaddress.org script. This gives you an "uncompressed" and "compressed" private key, hinting to uncompressed and compressed public keys derived from the private key. And from those you get the respective public addresses.

That's because it's difficult to get wallets that can send funds to a public address.

Seriously? How is it difficult for a wallet to send funds to a public address?

If you loaded it on Electrum and no wallet pooped up then it's definitely not a bitcoin wallet. Having 9 as the. First character means it could be any altcoin probably Ethereum doge or BCH. since a typical compressed bitcoin key starts with either "5" or "6"

Please, read more carefully what someone wrote: the 9 is the first digit of a very likely hexadecimal string representing 256 bits. And a compressed Bitcoin private key doesn't start with 5 or 6 but usually with K or L, see https://learnmeabitcoin.com/technical/keys/private-key/wif/#benefits

[hugyour]

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

[Cricktor]

~~~

First assumption: the hex string worth 256 bits represents a private key.

You converted it to WIF form and you can have an uncompressed public key from it and thus an uncompressed public address. The compressed public key gives you a different compressed public address.

I would check both, in my opinion there's no need to transfer funds to the public addresses. It should be fine to import both public addresses to Electrum which you could do on an online Electrum. Importing the public addresses gives you a watch-only wallet and doesn't put the private key at risk in any form (handle private keys on an air-gapped device for security reasons).

mempool.space should be reliable enough and when it doesn't show any balance for addresses checked and another blockexplorer yields the same result, so does the Electrum wallet with the imported addresses, I'd say, this is proof enough that there's no balance.

With no balance on both addresses (and neglecting the possibility of funds on P2PK public keys) we now know the hex string is no Bitcoin private key.


Second assumption: the hex string is something else.

Now a wide field opens, especially when your spouse didn't "backup" any further details. My suggestion to hash it with SHA256 one or multiple times gives you again a blob worth 256 bits. For peace of mind, I would check if those blobs treated as a Bitcoin or altcoin private key don't have any funds.

I doubt your spouse did something like this, but you never know what funny ideas even non-tech savvy people follow.

My other ideas were just a variation of the second assumption.


The thing is: unless you have other evidence that your spouse had some crypto coins, you don't know it he even had something at all in this field.

[nc50lc]

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.

So you've imported it to Electrum,
It can't scan P2PK transactions outside of its "sweep" feature, so you should still check if there's any associated P2PK output for that key just in case.

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?

Just use mempool.space blockexplorer again and paste the result "Public Key (130 characters [0-9A-F])" and "Public Key (compressed, 66 characters [0-9A-F])" to search.
If there's no result and you've already checked both compressed and uncompressed legacy addresses, it's safe to assume that it's not a Bitcoin Private Key.