Hex in estate - Bitcoin Core

[Old and tired]

So when going through my deceased uncles estate, I found a list of many hexadecimal numbers. They all are grouped with 64 characters. As this is the base for Bitcoin and I know my uncle was doing a lot with computers many years ago I was thinking it could be worth checking out.

Converting the hexadecimal to uncompressed and compressed wif was of course not an issue and using "importprivkey" and "rescanblockchain" in Bitcoin Core also easy.
After a full rescan in Bitcoin Core 25.2 the result was nada, zilch and nothing! Most likely these hexadecimal have nil purpose, but as I knew my uncle and he would not have saved this paper unless a good reason (unless he wanted me to chase ghosts!) I am starting to think that maybe Bitcoin Core 25.2 is to new.
To be sure to scan for early bitcoins (based on uncompressed keys) which Bitcoin Core version is the latest to use? Will Core 27.1 work? Or should I download an earlier version, if so what would be best?


Due to the above I have really been trying to read up on this subject and there is a statement in the release for 0.17.1 that makes me think there could be an issue with the database:
"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 do think this does mean the rescan will work, however with all the changes that's been over the years is it possible that scanning through the first years using a recent version might miss something?

Thanks.

[aliveNFT]

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

importprivkey

correctly, it should recognize both old uncompressed keys [used in the early days] and newer compressed ones.

[mocacinno]

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)

[ABCbits]

Converting the hexadecimal to uncompressed and compressed wif was of course not an issue and using "importprivkey" and "rescanblockchain" in Bitcoin Core also easy.

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.

[Cricktor]

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.

[apogio]

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!

[bizeodal]

I found a list of many hexadecimal numbers. They all are grouped with 64 characters. As this is the base for Bitcoin

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

[BlackHatCoiner]

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.

[nc50lc]

Converting the hexadecimal to uncompressed and compressed wif was of course not an issue and using "importprivkey" and "rescanblockchain" in Bitcoin Core also easy.
After a full rescan in Bitcoin Core 25.2 the result was nada, zilch and nothing! Most likely these hexadecimal have nil purpose, but as I knew my uncle and he would not have saved this paper unless a good reason (unless he wanted me to chase ghosts!)

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.

I wonder a bit why someone would store private keys in hex format which is a rather error prone format.

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.

[NotATether]

I wonder a bit why someone would store private keys in hex format which is a rather error prone format.

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.