Finding Hex Codes in Estate Bitcoin Core

So, while going through my late uncle’s estate, I stumbled upon a list of hexadecimal strings. They’re all 64 characters long, which is the format for Bitcoin. Given that my uncle was really into computers back in the day, I figured it might be worth checking out. Converting those hex codes to both uncompressed and compressed wif was easy. I also used "importprivkey" and "rescanblockchain" in Bitcoin Core without a hitch. But after doing a complete rescan with Bitcoin Core 25.2, I got nothing. Zip. Zero. Most likely, these hex codes don’t lead anywhere, but knowing my uncle, he wouldn’t have saved that paper without a solid reason (unless he just wanted me to chase ghosts). Now I'm starting to wonder if Bitcoin Core 25.2 is too recent for this. To make sure I can check for older bitcoins (using uncompressed keys), what’s the latest version of Core I should use? Will Core 27.1 work? Or do I need to download an older version? If so, which one is the best option? I’ve been digging into this topic and came across a statement in the release notes for version 0.17.1 that has me thinking there could be a database issue: "Note that the block database format also changed in version 0.8.0 and there is no automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading directly from 0.7.x and earlier without redownloading the blockchain is not supported. However, as usual, old wallet versions are still supported." I think this means the rescan should work, but with all the changes over the years, is it possible that scanning through the

Hi, Version 25.2 is still capable of scanning for both compressed and uncompressed addresses, no need to go back to an older version of bitcoin core specifically for this task. If you use correctly, it should recognize both old uncompressed keys [used in the early days] and newer compressed ones.

In case you need older versions, i have created Dockerfiles (and images) for allmost every major release going back to 2009... Bitcoin core v25.1 can be found here:  https://github.com/mocacinno/bitcoin_core_docker/tree/v25.1 I'd advice to read the dockerfile first, use it to build your own image after you've verified the Dockerfile, then run your own image without network (if possible) and use a version that is as recent as possible! I'm still in the startup phase of documentation, but the little documentation i already have can be found here: https://mocacinno.github.io/bitcoin_core_docker/ The page with user documentation is here: https://mocacinno.github.io/bitcoin_core_docker/userdocs/ it contains info on how to build and run pre-built images (eventough this documentation is far from complete)

What kind of address generated by Bitcoin Core? Legacy (have prefix "1")? SegWit (have prefix "3")? Native SegWit (have prefix "bc1q")? Anyway, command importprivkey have limitation where you can't choose address type. You might want to create new wallet with descriptor type and use this guide to import the key while specifying the address type, [HOW-TO] Import privkeys into a Bitcoin Core descriptor wallet.

I wonder a bit why someone would store private keys in hex format which is a rather error prone format. But it seems OP also only guessed it should be private keys, because... well... at least the size matches, 64 hex chars equals 32 bytes equals 256 bits. Could be entropy, too, but maybe less likely. If it's not documented what those numbers are, then good luck. Why did you start with Bitcoin Core v25.2, any specific reason? Use https://bitcoincore.org and not https://bitcoin.org for downloading Bitcoin Core. Always verify your download to be genuine! Good suggestions so far here from others. I'll emphasize that you need to work in a safe and preferably offline environment when you fiddle around with "naked" private keys and tools to convert them in more suitable formats. Don't do that on an online and hot machine which also could be used for daily internet shit.

Very good suggestions indeed but I have a question: Your uncle was a tech savvy person, based on what you said above. However, do you have any knowledge whether he was involved in Bitcoin? Have you ever had a conversation or anything similar? You know, unfortunately, just like it’s already mentioned, it’s highly unlikely that you will find what these numbers are without documentation. Bitcoin is a good guess and I really hope the research ends up well!

Hexadecimal has been a convenient way to represent binary data since the 1960s or earlier. It's not special to Bitcoin

Unfortunately, as already been said, grouping text to 64 hex characters could be much beyond Bitcoin. Passwords, messages, it could pretty much be anything. If you have access to his computer, search as much as possible to find anything related to Bitcoin. If, for example, there's an Electrum standalone file downloaded a few months or years ago, that should be alarming. But if you find nothing, then highly unlikely.

For that, please elaborate the steps that you've done or tools that you've used to encode your suspected Private Keys to WIF so we can confirm if it's done correctly or if it's what caused the negative scan result. Even if you've easily done it, it's best to have a second opinion on the accuracy of the procedures. Back when WIF isn't introduced yet (included in #574), some third-party scripts/tool exports prvKeys in HEX. The only chance that OP's list are prvKeys is if it's older than that commit, else, it's as the majority said.

It would have to be a backup generated by a different wallet software from Bitcoin Core. If OP is not finding anything from this address then it could mean that there's a (different) HD wallet derivation path involved. He should see if the data is a valid Armory or Multibit backup.