Please, I need help for converting a very old btc private key to WIF.

[bluecat4]

Many thanks Cricktor and nc50lc. Best regards.

[bluecat4]

Hi, I have a new doubt: Is coin control possible on a watch-only wallet in Electrum?

Thanks.

[LoyceV]

Is coin control possible on a watch-only wallet in Electrum?

Yes. Click View > Coins to enable the Coins tab if it's not showing yet. On the Coins tab, CTRL-select the ones you want, right-click to Add to coin control.

[bluecat4]

Is coin control possible on a watch-only wallet in Electrum?

Yes. Click View > Coins to enable the Coins tab if it's not showing yet. On the Coins tab, CTRL-select the ones you want, right-click to Add to coin control.

Ok, perfect. Thanks.

[bluecat4]

I found a very old Bitcoin private key. Searching online, I discovered that my private key is base64, has 44 characters, and ends in an equal sign. I only have the private key, I don’t have the seed phrase. I need to convert the private key to WIF format to import it into Electrum.

After some days-off, I continue with my normal life and with the “treasure hunting”. At first, like it’s in my first message I thougth it was base64, now I think there’s also could be base58Check. I thought this was going to be easier after the very serious problem to find it. I wasn’t able to convert it with bitaddress offline, it says something like “this is not a valid private key”. I’m sure it’s a bitcoin private key, I found it in a pen drive in 2 files (both with the same code), one of them with the name “btc private key”. Of course it’s possible that maybe I made a terrible mistake and copied the code wrong. To avoid this I copied and pasted it twice, includind characters that were not part of the key.

The private key or the wallet to be more precise was created in the old bitcoin client, bitcoin qt, in 2010. It has 44 characters and ends in an equal sign like I said in my first message. Additionally, there are 2 characters at the beginning and 2 at the end of the code that are not part of the private key. They are: =_ at the beginning and _= at the end. Inside are the 44 chars of the private key.

The code contains a prefix that starts with UTF-8. Bitcoin qt offered several options, at least two, of formats for the private key at that time: I remember there was a format with many characters ( maybe hex ? ) and at least there was another with far fewer chars. I chose the shorten version possible.

When I logged into bitcoin qt with my key, I think, if I remember correctly, I didn’t need to type the 44 chars. The reason was because the first characters were written on the screen by the program: the prefix UTF-8.

I’ve been thinking that maybe the prefix has one encoding and the rest of the key has another and that’s why bitaddress doesn’t recognize it as valid. In that case, it wouldn’t make much sense for it to be base64 when base64 is 44 chars, so why have two encodings instead of one ? Another case could be that it was base58Check and the prefix served to reduce the number of chars, but… why does it end in =?

I don’t know where the prefix ends, so the key starts with UTF-8, ends with =, and at some character the prefix ends and at the next one the rest of the key continues. I think this may be the biggest difficulty.

I downloaded Python yesterday on the same computer I used bitaddress offline. I hope this is the last time I connect to the internet with it, for security reasons. I have no programming knowledge like I said in my first post, but I guess I’ll have to use python for this.

Do you think that the key can actually have 2 different encodings ? Could this have any solution ?

Sorry for the length of this post. Many thanks.

[Cricktor]

You may want to have a look at which characters you find in your encoded string. As of https://en.wikipedia.org/wiki/Base64 Base64 uses all A-Z, a-z, 0-9 and two other characters, usually + and / and = for padding.

Base58check uses only a smaller subset and avoids symbols that could be ambigous in most type faces. Additionally it has a partial hash checksum embedded. See here for symbols of Base58: https://learnmeabitcoin.com/technical/keys/base58/

In some cases it might not be possible to distinguish Base64 from Base58 depending on the sample string size. Base58check should be distinguishable because it must pass the checksum test as long as it's not crippled.

A WIF private key is composed of a prefix byte, the private key bytes, optional compression indicator byte and finally a partial hash checksum of four bytes, then all encoded with Base58. See e.g. here for details: https://learnmeabitcoin.com/technical/keys/private-key/wif/

I haven't used Bitcoin-GUI as now Bitcoin Core was called in those early days of 2010. I used Bitcoin-GUI on Windows OS in 2011 earliest. In 2011 I didn't fiddle much around with it, just mined some coins and moved them around. I didn't touch private keys at that time at all, didn't see a need for it until I had to recover a wallet from a dying harddisk many years later.

I don't think the standard Bitcoin client software ever asked for a wallet encryption passphrase when it was opened. But I may not understood what you were writing about your early wallet.

[bluecat4]

You may want to have a look at which characters you find in your encoded string. As of https://en.wikipedia.org/wiki/Base64 Base64 uses all A-Z, a-z, 0-9 and two other characters, usually + and / and = for padding.

Base58check uses only a smaller subset and avoids symbols that could be ambigous in most type faces. Additionally it has a partial hash checksum embedded. See here for symbols of Base58: https://learnmeabitcoin.com/technical/keys/base58/

In some cases it might not be possible to distinguish Base64 from Base58 depending on the sample string size. Base58check should be distinguishable because it must pass the checksum test as long as it's not crippled.

A WIF private key is composed of a prefix byte, the private key bytes, optional compression indicator byte and finally a partial hash checksum of four bytes, then all encoded with Base58. See e.g. here for details: https://learnmeabitcoin.com/technical/keys/private-key/wif/

I haven't used Bitcoin-GUI as now Bitcoin Core was called in those early days of 2010. I used Bitcoin-GUI on Windows OS in 2011 earliest. In 2011 I didn't fiddle much around with it, just mined some coins and moved them around. I didn't touch private keys at that time at all, didn't see a need for it until I had to recover a wallet from a dying harddisk many years later.

I don't think the standard Bitcoin client software ever asked for a wallet encryption passphrase when it was opened. But I may not understood what you were writing about your early wallet.

UTF-8 contains a hyphen, this symbol does not appear in the base64 alphabet. The index 63 is / or _ according to some articles I've red ( but the char - it's not on the list ). I think there can be two encodings, because UTF-8 (because of the hyphen) cannot be base64.

English isn't my native language, and I sometimes struggle to express myself. What I mean is that with this version of the private key, I didn't have to type the full key when logging in, so it wasn't a password. Let's take an example with a fake key, for example: UTF-8_ZZ_Z1aAAAAAAAAAAAAb6(...)=, and the prefix is UTF-8_ZZ_Z1, so I would have to type the rest aAAAAA(...)=, without typing the prefix.The problem is that I don't know where the prefix ends in my key. I use the word "prefix", but I don't know if it's correct.

Thanks.

[Cricktor]

I know "UTF-8" as name or designation for a character encoding scheme which is able to encode all over 1 million Unicode symbols. It uses variable length encoding with one to four bytes per single symbol. See https://en.wikipedia.org/wiki/UTF-8 and somewhat more elaborate wording when you ask Google for "what is UTF-8" and look at the KI generated "search result" or rather explanation.

Regarding the rest of the "prefix", I can't provide any help because I haven't seen such a construct and have no idea what has generated such a string of symbols/characters.

[bluecat4]

I haven't found the solution yet. During this time, I've learned some very basic Python concepts. It seems my private key is encoded in base64url. It's 44 chars long and 32 bytes wide. I'm using a laptop with no internet connection. My key is a version of WIF that I used because it was shorter. The 44 character key was divided into 2 parts:

The first part was fixed, acting as a prefix in the program. It consisted of the first 8 or 9 characters of the key. This part wasn't typed, as a way to avoid exposing the full key  when using it online. The problem is that I  don't remember exactly where the split between the first and the second part was. My key starts with UTF-8, and contains underscores and hyphens.

The second part, the  rest of the key had to be typed in order to use it.

The program stated that the full key was the 44 characters, and that it could be exported using a simple Python script. So the key included both the typed part and the fixed prefix.

So I have the full 44 character string. There are 2 main ideas:

* Many of the chars in my string matched the WIF. They were different at the beginning and the end, and maybe sligghtly diferent in the middle, but most of the middle chars were identical and in the same order.

* The program ( Bitcoin Qt ) said that converting it to exportable WIF format could be done easily with a simpe Python script.

My key is like tis example: UTF-8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM=  (44chars, base64url)

I assumed my key was a textual representation of the WIF key, but without the mainnet prefix and checksum, since it decodes to 32 bytes. I added the mainnet prefix and checksum to the whole string, but the resulting WIF looks completely different, so that seems wrong. Then I tried applying the checksum only to the prefix (testing different split points in Python), but the resulting WIF still makes no sense, and does not make any characters.

I remember that the prefix ( the fixed part ) was important to calculate the checksum. What I am sure about is that my key shared many characters with the original WIF. Now I think that maybe the prefix generates the mainnet prefix and the checksum, but without doble SHA, the key idea is that most of the middle characters should remain the same to form the WIF.

Chatgpt suggested I use the Electrum console. I tried it for the first time, of course on my PC without an internet connection, but I didn't get any results. I need more practice. Google's AI also indicated that my key might be a raw private key with a deterministic checksum and a hardcoded prefix.

I know perfectly well that my private key is very unusual and that the problem is complex. I'd like to follow more leads to try out possible solutions. Could you give me some help with this ? Thank you.

[LoyceV]

I know perfectly well that my private key is very unusual and that the problem is complex.

Your explanation doesn't make it any easier to understand what exactly you've created back in the days. Did you create your own kind of storage system, or do you have a standard 44 bit base64 key?

[nc50lc]

-snip- acting as a prefix in the program

I noticed that you've been mentioning "the program" but didn't specify that specific application or script.
Then just a few lines below, you mentioned "The program ( Bitcoin Qt )".
But the descriptions of "the program" above like the "split" doesn't look like it's a Bitcoin Core (GUI) feature.

It would be best to be precise on which application/script/tool names that you've tried and the steps that you've done including the commands used.
Screenshots (without the actual keys, of course) would also be great.

since it decodes to 32 bytes. I added the mainnet prefix and checksum to the whole string, but the resulting WIF looks completely different, so that seems wrong. Then I tried applying the checksum only to the prefix (testing different split points in Python), but the resulting WIF still makes no sense, and does not make any characters.

Perhaps it's an issue with your WIF encoder?
Because a single wrong character can produce an entirely different checksum bytes, thus a different last few characters.
Can you show the Python code that you're using to convert it to WIF? (please use [code][/code] tags on this)

And how can you tell that the result is wrong?
Did Electrum or Bitcoin Core detected that it's an invalid encoding or it's just empty when the wallet sync?

[bluecat4]

I know perfectly well that my private key is very unusual and that the problem is complex.

Your explanation doesn't make it any easier to understand what exactly you've created back in the days. Did you create your own kind of storage system, or do you have a standard 44 bit base64 key?

Bitcoin Qt ( 2010 ) had a button that transformed the WIF into a shorter and more secure version. My key is 32 bytes long. Bitcoin Qt explained how to convert it to WIF with a simple script, but I don't remember how.


[/quote]

And how can you tell that the result is wrong?
Did Electrum or Bitcoin Core detected that it's an invalid encoding or it's just empty when the wallet sync?
[/quote]

Because many of the middle characters of my key matched the middle characters of the WIF. So, if no character matches, it's clear that the obtained wif is not the correct one.

 
------


Chatgpt now says that it seems I have a non-standard checksum, a simple custom checksum, so I just need to apply a SHA to the prefix ( the first part of my key ). What I don't understand is why the mainnet would already be included in my key. Now I copy and paste the conclusion about it of chatgpt:


✅ Conclusion about your custom format

1-Single SHA on part of the prefix

Your checksum is custom and only applies to a portion of the fixed prefix at the start of your 32-byte key.

The prefix itself may occupy 8–9 bytes within the key, but typically the SHA is applied only to the first 4 bytes of that prefix.

The remaining bytes of your 32-byte key do not participate in this checksum.

2-Prefix likely contains the mainnet byte

Standard WIF uses a 1-byte prefix for network: 0x80 for mainnet, 0xEF for testnet.

Even though your private key is exactly 32 bytes, the prefix portion at the start likely includes the mainnet indicator byte.

This allows your key to be recognized as mainnet while keeping the key at 32 bytes total.

3-Why the central part matches the WIF

The middle section of your Base64url string corresponds directly to the raw private key bytes inside the WIF.

That’s why visually it shares characters with the WIF representation, even though the checksum and encoding differ.

💡 In short:

Your format is a custom WIF-like encoding: a 32-byte key whose first 8–9 bytes form a fixed prefix (likely containing the mainnet byte), with a checksum calculated via a single SHA applied only to the first 4 bytes of that prefix, followed by the remaining bytes of the private key. This explains both the “fixed start” and the similarity of the middle portion to a standard WIF.

[Cricktor]

If you used your own code to compute stuff, how about you show us your code (remove sensitive data like private key fragments or what else shouldn't leak into public)?

That way knowledgeable people here can spot flaws. I'm thinking about errors like: do you compute the checksum from raw bytes or from strings of hex characters.

If you didn't code yourself, which tools did you use and how?

Also, if you don't understand fully what you're doing, it's hard to judge if LLM output is sound and not some halluzination. In most cases it sounds sound but that doesn't mean it's correct, especially in niche areas.

[nc50lc]

3-Why the central part matches the WIF

The middle section of your Base64url string corresponds directly to the raw private key bytes inside the WIF.

That’s why visually it shares characters with the WIF representation, even though the checksum and encoding differ.

This is why I've mentioned that a different checksum makes the last few characters of the WIF different.

I also noticed that you've been mentioning a WIF which you compare the result of your WIF encoder.
Is it for testing purposes or something else?

What you need to do is to check which one has the correct checksum (the one you're comparting it to or the newly encoded one), mark the one with the wrong checksum.
It's easy to tell when you try to import it and the client shows "invalid encoding" or something similar.
Using the same LLM/AI to code your "checksum check" may just reproduce the error that it's done when encoding it, so don't.
And don't use the tool that always output a WIF with incorrect checksum.
Then, only use the one with the correct checksum.

If the WIF is different that what you expect due to having a different checksum, the actual private key should still be the same unless you messed up the encoding which will be detected by the client.
And if it successfully import (correctly encoded), but if the shows no history when imported (both compressed and uncompressed), then the actual private key is really empty or you've encoded the wrong 32Bytes.
You don't have to find other ways to encode it, the important part is private key that you've encoded.

[bluecat4]

3-Why the central part matches the WIF

The middle section of your Base64url string corresponds directly to the raw private key bytes inside the WIF.

That’s why visually it shares characters with the WIF representation, even though the checksum and encoding differ.

This is why I've mentioned that a different checksum makes the last few characters of the WIF different.

I also noticed that you've been mentioning a WIF which you compare the result of your WIF encoder.
Is it for testing purposes or something else?

I only have my key, but I remember perfectly that most of the central chars of the wif matched with my key.

[nc50lc]

I only have my key, but I remember perfectly that most of the central chars of the wif matched with my key.

Okay, so it's based from memory then.
Anyways, keep us updated with the result once you've tried the suggestions in the previous replies.

If only you know the specific transaction output that your private key can spend, that would've given a big clue.
E.g.: Electrum can't sync P2PK UTXO with "Import" but it can spend it with "Sweep", so if you've used Electrum but used Import, you might had a false-negative result.
E.g.2: Or if the output is some standard but uncommon script like 1-of-1 P2SH MultiSig, most clients will not be able to restore it without you manually creating its redeem script.