Invalid private key error

[o_e_l_e_o]

Unfortunately, the seller has never disclosed to me the address of my purchase hence I don’t have any clue as to what I own or I need to take into consideration before engaging third party wallet recovery.

You don't need to know an address in order to attempt to brute force. The checksum will only be valid for 1 out of every ~4.3 billion possibilities, meaning you can easily simply look up the address of any valid key that you find.

Here is the statement I am curious about:

“On March 7, 2014, Mt.Gox Co., Ltd. confirmed that an old-format wallet which was used prior to June 2011 held a balance of approximately 200,000 BTC," the statement said.”   As reported CNN money - https://money.cnn.com/2014/03/21/technology/mt-gox-missing-bitcoin/index.html.

None of this is relevant to you. It does not matter what type of wallet created the WIF private key you are trying to recover. It is either a valid WIF key, or it isn't. The only thing that might change is the locking script related to your private key, but you won't be able to even start thinking about that until you have successfully brute forced the private key.

[1714483799]

1714483799

[1714483799]

1714483799

[lionheart78]

Hi there,
    Can anybody explain what is meant by “bitcoins found in ‘old format’ wallet” and examples of their public keys/private keys.  Thanks.

I think it means Bitcoin stored in an old format wallet where old format wallet refers to a legacy or non-segwit format.  An example of public key of the old fromat wallet is an address string that might be start in 1 such as "1cDwMSxYstvetZTFn54X5m4GFgzxJaMDo5" and an example of the private key in the old format might be a string of characters that starts with 5 like "5WzTsXwOe1pm601tcNygAGRdCckhHJBGFsvd3VyK55PZXj3tL".

Here is the statement I am curious about:

“On March 7, 2014, Mt.Gox Co., Ltd. confirmed that an old-format wallet which was used prior to June 2011 held a balance of approximately 200,000 BTC," the statement said.”   As reported CNN money - https://money.cnn.com/2014/03/21/technology/mt-gox-missing-bitcoin/index.html.

Can anyone please help me understand the above article of old-format wallet used prior to June 2011. Thanks

This may be an answer to your question

The statement you are referring to is about the now-defunct cryptocurrency exchange Mt. Gox, which was one of the largest and most popular exchanges for buying and selling bitcoins in the early days of the Bitcoin network.

In the statement, Mt. Gox is confirming that an old-format wallet that was used on the exchange prior to June 2011 held a balance of approximately 200,000 BTC. This means that the bitcoins were stored in an old-format wallet, which is also known as a "legacy" or "non-segwit" wallet. These wallets were the original way that bitcoins were stored on the Bitcoin network and used a different format for the public and private keys compared to the current format.

The old-format wallets were less secure than the new format wallets and are more vulnerable to hacking. It is possible that this old-format wallet was compromised by hackers, which led to the loss of the 200,000 BTC.

This statement is made by Mt.Gox in the year 2014, and it is indicating that they discovered an old-format wallet that they used prior to June 2011 held a balance of approximately 200,000 BTC. It is unclear what happened to those bitcoins, but it is reported that Mt. Gox filed for bankruptcy in 2014 after losing 850,000 bitcoins, including 750,000 belonging to customers, and 100,000 of the company's own bitcoins.
It is important to note that Mt.Gox's incident is a cautionary tale for the crypto community to always keep their private keys secure and use the latest security measures for their wallets.

[Tofee]

I appreciate the response by lionheart78.

 I tried 1cDwMSxYstvetZTFn54X5m4GFgzxJaMDo5 on blockchain and was getting error. Also, the pvt key does not seem to be WIF base58 format. As mentioned in the earlier post, private key in WIF base58 omits few letters to avoid human sight error, and it starts with ‘5’ followed by ‘H’, ‘J’ or ‘K’ and has total 51 characters. But the key mentioned by lionheart78 though starts with 5 but is followed by letter ‘W’ and has number ‘0’ included and does not total up to 51 characters. C

Can anybody advise me where am I going wrong and if possible please let me know any reference to gain some information.

Thanks

[o_e_l_e_o]

Can anybody advise me where am I going wrong and if possible please let me know any reference to gain some information.

The problem is that the strings provided by lionheart78 are not valid.

I don't know where he got them from, or is he just made them up himself, but the WIF key he provided is the wrong length and contains invalid characters, and is not a valid private key. The address he provided is similarly invalid, with an invalid checksum. The correct checksum for that string would give the following (valid) address: 1cDwMSxYstvetZTFn54X5m4GFgztvxDw4

[Tofee]

Can anybody advise me where am I going wrong and if possible please let me know any reference to gain some information.

The problem is that the strings provided by lionheart78 are not valid.

I don't know where he got them from, or is he just made them up himself, but the WIF key he provided is the wrong length and contains invalid characters, and is not a valid private key. The address he provided is similarly invalid, with an invalid checksum. The correct checksum for that string would give the following (valid) address: 1cDwMSxYstvetZTFn54X5m4GFgztvxDw4

Thanks for your response. I sincerely appreciate your efforts. Please let me know which website or tool is the best for checking the checksum and correcting the public address. Thanks.

[Tofee]

Hi there,
    Can anybody explain what is meant by “bitcoins found in ‘old format’ wallet” and examples of their public keys/private keys.  Thanks.

I think it means Bitcoin stored in an old format wallet where old format wallet refers to a legacy or non-segwit format.  An example of public key of the old fromat wallet is an address string that might be start in 1 such as "1cDwMSxYstvetZTFn54X5m4GFgzxJaMDo5" and an example of the private key in the old format might be a string of characters that starts with 5 like "5WzTsXwOe1pm601tcNygAGRdCckhHJBGFsvd3VyK55PZXj3tL".

Here is the statement I am curious about:

“On March 7, 2014, Mt.Gox Co., Ltd. confirmed that an old-format wallet which was used prior to June 2011 held a balance of approximately 200,000 BTC," the statement said.”   As reported CNN money - https://money.cnn.com/2014/03/21/technology/mt-gox-missing-bitcoin/index.html.

Can anyone please help me understand the above article of old-format wallet used prior to June 2011. Thanks

This may be an answer to your question

The statement you are referring to is about the now-defunct cryptocurrency exchange Mt. Gox, which was one of the largest and most popular exchanges for buying and selling bitcoins in the early days of the Bitcoin network.

In the statement, Mt. Gox is confirming that an old-format wallet that was used on the exchange prior to June 2011 held a balance of approximately 200,000 BTC. This means that the bitcoins were stored in an old-format wallet, which is also known as a "legacy" or "non-segwit" wallet. These wallets were the original way that bitcoins were stored on the Bitcoin network and used a different format for the public and private keys compared to the current format.

The old-format wallets were less secure than the new format wallets and are more vulnerable to hacking. It is possible that this old-format wallet was compromised by hackers, which led to the loss of the 200,000 BTC.

This statement is made by Mt.Gox in the year 2014, and it is indicating that they discovered an old-format wallet that they used prior to June 2011 held a balance of approximately 200,000 BTC. It is unclear what happened to those bitcoins, but it is reported that Mt. Gox filed for bankruptcy in 2014 after losing 850,000 bitcoins, including 750,000 belonging to customers, and 100,000 of the company's own bitcoins.
It is important to note that Mt.Gox's incident is a cautionary tale for the crypto community to always keep their private keys secure and use the latest security measures for their wallets.

Thanks for your response. Please refer to the response given by o_e_l_e_o where checksum is corrected and the address checked on blockchain explorer shows that it has never been used. Can you provide any references to your inputs. Just curious because the private key you provided has several discrepancies. Thanks

[o_e_l_e_o]

Thanks for your response. I sincerely appreciate your efforts. Please let me know which website or tool is the best for checking the checksum and correcting the public address. Thanks.

To fix that address I simply decoded it to hex, calculated the correct checksum, and then re-encoded it in Base58. You could probably use a site like https://gobittest.appspot.com to do this online if you wanted.

I really don't know why you want to, though. None of this is in any way relevant whatsoever to your private key with the incorrect characters. Have you tried brute forcing it with btcrecover yet as I suggested above? Do you want me to try for you?

[Tofee]

Thanks for your response. I sincerely appreciate your efforts. Please let me know which website or tool is the best for checking the checksum and correcting the public address. Thanks.

To fix that address I simply decoded it to hex, calculated the correct checksum, and then re-encoded it in Base58. You could probably use a site like https://gobittest.appspot.com to do this online if you wanted.

I really don't know why you want to, though. None of this is in any way relevant whatsoever to your private key with the incorrect characters. Have you tried brute forcing it with btcrecover yet as I suggested above? Do you want me to try for you?

Thanks for your response.

 I did know about the web site which you have mentioned but since it’s online, I am not comfortable checking out the checksum of the private key which I have in order to gather info of the corresponding pubkey address.

I wish to interact web site offline availability, hence I enquired from you. I am currently using FinderOuter offline but I have not come across checksum of pub address or private key, since the private key I have has been showing checksum errors on several occasions.

As I mentioned earlier on my posts, my key starts with 5 but is followed by ‘F’ and has ‘I’ included as one of the characters and ‘l’ on one of the last seven characters (which I presume as checksum) of the key.Please correct me if I am wrong.

My current position is that I am unable to share this key with any recovery/investigation due to unknown public address key and their total number of bitcoins. I am in the process of getting other details of the transaction and then I may have other details which can be shared. Thanks again for your responses.

[o_e_l_e_o]

I did know about the web site which you have mentioned but since it’s online, I am not comfortable checking out the checksum of the private key which I have in order to gather info of the corresponding pubkey address.

You won't be able to calculate a valid checksum for your private key since it contains invalid characters. That website will simply throw an "Invalid Base58 encoding" error if you try.

I am currently using FinderOuter offline but I have not come across checksum of pub address or private key, since the private key I have has been showing checksum errors on several occasions.

As I covered above, this does not mean your checksum is incorrect. A checksum error simply means the checksum does not match the rest of the key. Given that the rest of the key is invalid as it contains invalid characters, there is no checksum in existence which will be valid. Every possible checksum will return the same error. You are focusing on the wrong things here.

As I mentioned earlier on my posts, my key starts with 5 but is followed by ‘F’ and has ‘I’ included as one of the characters and ‘l’ on one of the last seven characters (which I presume as checksum) of the key.Please correct me if I am wrong.

The checksum encodes 8 hex characters in to base58 characters, meaning it will be either the last 5 or 6 characters which are the checksum.

My current position is that I am unable to share this key with any recovery/investigation due to unknown public address key and their total number of bitcoins.

I am happy to attempt to brute force it for free, at least for all the straightforward character replacements and similar we discussed earlier. Completely understand if you don't want to risk it though.

[Tofee]

I did know about the web site which you have mentioned but since it’s online, I am not comfortable checking out the checksum of the private key which I have in order to gather info of the corresponding pubkey address.

You won't be able to calculate a valid checksum for your private key since it contains invalid characters. That website will simply throw an "Invalid Base58 encoding" error if you try.

I am currently using FinderOuter offline but I have not come across checksum of pub address or private key, since the private key I have has been showing checksum errors on several occasions.

As I covered above, this does not mean your checksum is incorrect. A checksum error simply means the checksum does not match the rest of the key. Given that the rest of the key is invalid as it contains invalid characters, there is no checksum in existence which will be valid. Every possible checksum will return the same error. You are focusing on the wrong things here.

As I mentioned earlier on my posts, my key starts with 5 but is followed by ‘F’ and has ‘I’ included as one of the characters and ‘l’ on one of the last seven characters (which I presume as checksum) of the key.Please correct me if I am wrong.

The checksum encodes 8 hex characters in to base58 characters, meaning it will be either the last 5 or 6 characters which are the checksum.

My current position is that I am unable to share this key with any recovery/investigation due to unknown public address key and their total number of bitcoins.

I am happy to attempt to brute force it for free, at least for all the straightforward character replacements and similar we discussed earlier. Completely understand if you don't want to risk it though.

Thanks for your response. In my key, the invalid character is within the last four characters, hence I conclude that the checksum is not base58 format. Hence, in FinderOuter, I have last six unknown characters and one unknown character in the middle of the key as basic search. I am replacing ‘F’ with H,J,K. This search will take a very very long time for completion. Thanks

[o_e_l_e_o]

Hence, in FinderOuter, I have last six unknown characters and one unknown character in the middle of the key as basic search. I am replacing ‘F’ with H,J,K. This search will take a very very long time for completion.

This search is trivial to do if you set up btcrecover properly. You have three unknowns for the first character, and 58 unknowns for the character in the middle. Even assuming the worst case scenario of the checksum only being 5 characters, giving you another unknown character in the 6th from last position, then there are only 3*58*58 possibilities, since the last 5 characters don't need to be brute forced since they will be calculated from the rest of the key. This is only 10,092 possibilities, which can be searched in under a second.

[Tofee]

Hence, in FinderOuter, I have last six unknown characters and one unknown character in the middle of the key as basic search. I am replacing ‘F’ with H,J,K. This search will take a very very long time for completion.

This search is trivial to do if you set up btcrecover properly. You have three unknowns for the first character, and 58 unknowns for the character in the middle. Even assuming the worst case scenario of the checksum only being 5 characters, giving you another unknown character in the 6th from last position, then there are only 3*58*58 possibilities, since the last 5 characters don't need to be brute forced since they will be calculated from the rest of the key. This is only 10,092 possibilities, which can be searched in under a second.

Thanks for your response. I am trying to install BTCrecover on Ubuntu 22.0 but it is having issues with Ripemd160. Ripemd160 is not working and tests are not working.

 I assume the last seven characters on a private key is based on checksum then the search would have been 3*58.

I tried it on FinderOuter but the search is 3*58*58*58*58*58*58*58*58.
Ie 3=first character after 5.
Than 58 for one invalid character.
Then last seven characters for checksum ( 58 x 7 ).

Had FinderOuter provisions for elimination of checksum and calculated only the main characters then the search for valid key would have been very simple.

If the seller who emailed me the private key has given me a valid key.

As one of the response stated that if the seller has scammed me then none of the above search efforts are of any use.

Hence, currently the task is unpredictable.

Thanks

[Tofee]

Unfortunately, the seller has never disclosed to me the address of my purchase hence I don’t have any clue as to what I own or I need to take into consideration before engaging third party wallet recovery.

You don't need to know an address in order to attempt to brute force. The checksum will only be valid for 1 out of every ~4.3 billion possibilities, meaning you can easily simply look up the address of any valid key that you find.

Here is the statement I am curious about:

“On March 7, 2014, Mt.Gox Co., Ltd. confirmed that an old-format wallet which was used prior to June 2011 held a balance of approximately 200,000 BTC," the statement said.”   As reported CNN money - https://money.cnn.com/2014/03/21/technology/mt-gox-missing-bitcoin/index.html.

None of this is relevant to you. It does not matter what type of wallet created the WIF private key you are trying to recover. It is either a valid WIF key, or it isn't. The only thing that might change is the locking script related to your private key, but you won't be able to even start thinking about that until you have successfully brute forced the private key.

I am trying to locate the seller or the sellers who had the capability of selling bitcoins during the period 2009 to 2011 and the name a few of  them arise are Mt.Gox and Coinpal.

If X = Mt.Gox (exchange ) or wholesale provider.
If Y = marketer or internet marketing links/blogs administrator or distributor
If Z = purchaser or buyer.

What if the selling system was designed that bitcoins would be sold by the exchange Mt.Gox X (first party) on an order placement basis by second party  Y (person who is marketing through link advertisements on internet such as Yahoo finance and other blogs) to third party Z (third party is purchaser or me in this case) then in this scenario X is instructed for delivery of bitcoins by providing the access authority or Privatekey to Z ( delivery destination email address).

In this above mentioned scenario, if I am the legal owner for accessing those bitcoins but by virtue if the privatekey provided by X without providing details explanation of how to execute the key and if it is not valid key then how am I going to own them.

There are other arguments which arise apart from this as well. Please give it a thought of the scenario I mentioned above and please let me know your opinion. Critics are welcome.
Thanks

[Romoe]

I assume the last seven characters on a private key is based on checksum then the search would have been 3*58.

I tried it on FinderOuter but the search is 3*58*58*58*58*58*58*58*58.
Ie 3=first character after 5.
Than 58 for one invalid character.
Then last seven characters for checksum ( 58 x 7 ).

Had FinderOuter provisions for elimination of checksum and calculated only the main characters then the search for valid key would have been very simple.

1. Checksum part for WIF private key starting with '5' is only last 5 character (Not 7)
2. If you assured that there are 2 Char wrong, So all possible valid key that can generated is only 3x58. ( = 174 key)
3. After convert those key to P2PKH address (BTC address starting with '1'),You can check all of that 174 address if it have balance or not.  (It takes less than 1 minute in bitcoin blockchain inquiry API)

All the above processes can be done with one python script

[Tofee]

I assume the last seven characters on a private key is based on checksum then the search would have been 3*58.

I tried it on FinderOuter but the search is 3*58*58*58*58*58*58*58*58.
Ie 3=first character after 5.
Than 58 for one invalid character.
Then last seven characters for checksum ( 58 x 7 ).

Had FinderOuter provisions for elimination of checksum and calculated only the main characters then the search for valid key would have been very simple.

1. Checksum part for WIF private key starting with '5' is only last 5 character (Not 7)
2. If you assured that there are 2 Char wrong, So all possible valid key that can generated is only 3x58. ( = 174 key)
3. After convert those key to P2PKH address (BTC address starting with '1'),You can check all of that 174 address if it have balance or not.  (It takes less than 1 minute in bitcoin blockchain inquiry API)

All the above processes can be done with one python script

Thanks for your response.
As per your response, in FinderOuter, I will have to include 5 x 58 in place of checksum. Accordingly, the search would be 2 (for missing chapters) + 5(for checksum characters) = 7 * characters.

Unfortunately, I don’t have the python script you referenced. If you can, please send me the link. Thanks.

[Romoe]

Unfortunately, I don’t have the python script you referenced. If you can, please send me the link. Thanks.

I can create it for you, but I need to known where the wrong position is.
For example, 5JXB[]hvvfQaT7GxoN7BGicZST25uGhLJ5aK9y3SS3LL[]766tfaS, the wrong position is '5' and '44'

I don't check this site often, Can you contact me in telegram? [Telegram: @Panadawn]