Attempting to decode a damaged Base58 WIF to hex

[NotATether]

Let's say that x consecutive characters inside a WIF are lost but the rest are known.

Suppose you're trying to get the minimum and maximum possible possible values of this WIF given the missing characters. According to my knowledge, that is supposed to be between 11111..... and zzzzz...... (length depends on how many characters are lost).

Also suppose at first you're dealing with compressed privatekeys, so there's going to be an "01" before the 4 checksum bytes.

This is where things get obnoxious.

Once you decide the WIF (using Base58 - not base58check as that will fail) substituting the lost characters for the smallest and biggest ones, and after removing the checksum and 01 bytes on the right (5) and the "80" byte on the left (1), the hex of the WIF with smaller substituted chars (111111) is larger than the one with bigger subs (zzzzz). How is that possible?

[1714591496]

1714591496

[1714591496]

1714591496

[1714591496]

1714591496

[Coding Enthusiast]

the "80" byte on the left

Because the byte you discarded wasn't 0x80.
When you are treating the Base-58 string as an integer ignoring the checksum, etc. you have to be careful not to hit an edge case such as the one in that other topic.

When you are decoding Kw111... you end up with {0x79, 0x76, ...} bytes which is obviously an invalid permutation because of invalid version byte. So you have to increment until you get to 0x80 first and use that as your starting point. Meaning: Kw1111111112 -> Kw1111111113 -> Kw1111111114 -> ... Kw111111111z -> Kw1111111121 -> Kw1111111122 ...
If you don't do that, your "big" value using z's (Kwzzz...) would be {0x80, 0x4c, ...} and since an integer starting with 0x76 is bigger than an integer starting with 0x4c you end up with a bigger start than the end.

[NotATether]

the "80" byte on the left

Because the byte you discarded wasn't 0x80.
When you are treating the Base-58 string as an integer ignoring the checksum, etc. you have to be careful not to hit an edge case such as the one in that other topic.

When you are decoding Kw111... you end up with {0x79, 0x76, ...} bytes which is obviously an invalid permutation because of invalid version byte. So you have to increment until you get to 0x80 first and use that as your starting point. Meaning: Kw1111111112 -> Kw1111111113 -> Kw1111111114 -> ... Kw111111111z -> Kw1111111121 -> Kw1111111122 ...
If you don't do that, your "big" value using z's (Kwzzz...) would be {0x80, 0x4c, ...} and since an integer starting with 0x76 is bigger than an integer starting with 0x4c you end up with a bigger start than the end.

I see.

This means that I have to find the first K..... compressed PK that makes an 0x80 version byte and that's going to correspond to the private key 0x1, right?

[PawGo]

Maybe you must take into account correct boundaries?
uncompressed minimum:
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf
compressed minimum:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn

uncompressed maximum:
5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDU2KYEqetqj84qw
compressed maximum:
L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFLaHLuZ9

On the other hand:
Where are the missing characters? How many? If you think about converting WIF solving into tools like bitCrack, it is not always possible - only for characters on very left side (at the beginning), where stride is >= then 58^40 (maybe one character more on right, I do not remember now).
Otherwise stride will collide with checksum (and/or compression flag) and then it is not linear - not possible to use BitCrack!

If you need other help, for example with configuring my WifSolver, let me know.

[Coding Enthusiast]

This means that I have to find the first K..... compressed PK that makes an 0x80 version byte and that's going to correspond to the private key 0x1, right?

Yes, that would make the starting point. Although brute forcing it may take a long time itself since it is 10 missing characters so you may need to find the closest thing by manually modifying the characters.

[stanner.austin]

i have made some test too.

sample "01" WIF key compressed "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn"
sample used is "KwDiBf****GbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn"

Code:

Found 800000000000000000000000000000000000000000000000000000000000000001014671fc3f
Found KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn
--- 80.92910385131836 seconds ---
         86432970 function calls (86432959 primitive calls) in 80.933 seconds

only 4 digit recovery take 80sec signal core, cpu use intel7 10gen to try all 0 to 58 digit from base58 index.
no idea how much it will take for 10 digits. but for sure not good for CPU.. GPU may help on this.

[NotATether]

Thanks for the answers.

In particular, is the WIF that begins with: "L1111111111......." a valid private key? Leaving out all the checksum bytes of course so those can be anything. I just want to know if it's valid to place a sequence of 1's inside a private key WIF (I read somewhere that that may not be the case for addresses), as the number "1" in base58 is equal to the number "0" in base10.

[PawGo]

Thanks for the answers.

In particular, is the WIF that begins with: "L1111111111......." a valid private key? Leaving out all the checksum bytes of course so those can be anything. I just want to know if it's valid to place a sequence of 1's inside a private key WIF (I read somewhere that that may not be the case for addresses), as the number "1" in base58 is equal to the number "0" in base10.

Of course. It is just a text in given encoding. It is only our (people) ability to find patterns which looks "nice"...
WIF L111111111111111111111111111111111111111111111CbeH6a is fully correct, leads to private key
70cfa0d40309798a5bd144a396478b5b5ae3305b7413601b18767666bdb2f800
which is key like any other...
Some strings looks "nice" in binary, others in hex and others in base58 encoding....

[NotATether]

Of course. It is just a text in given encoding. It is only our (people) ability to find patterns which looks "nice"...
WIF L111111111111111111111111111111111111111111111CbeH6a is fully correct, leads to private key
70cfa0d40309798a5bd144a396478b5b5ae3305b7413601b18767666bdb2f800
which is key like any other...
Some strings looks "nice" in binary, others in hex and others in base58 encoding....

Also, is the checksum always going to be six base58 characters like this one?

[PawGo]

Not really. The rule is that checksum takes last 8 hex characters of decoded WIF. And for compressed there are also 2 characters of compression flag. All together may takes in general last 5 characters of WIF and very often also 6th character. All depends on values of checksum and flag, and how they are convertible to base58.
In my WifSolver for wifs with missing end I think I made assumption that last 5 characters are not important (are checksum).

[pooya87]

(I read somewhere that that may not be the case for addresses), as the number "1" in base58 is equal to the number "0" in base10.

It is the first digit so it represents 0 but you may be thinking of the starting 1s like 1abc in which case it is replaced with a zero when decoding (or 1 is added for each starting zero) and we do it because in this encoding we convert an integer to the base58 and vice versa, it is important to know the number of zeros it had at the beginning or we may end up with a shorter invalid result.

[cixegz]

i speak little bit englsih
@NotATether help me this is your post 10/10/21 i need tips and python code

@pooya87 thanks i am open new topic solve this any one i will donate 2022$
click read my topic https://bitcointalk.org/index.php?topic=5379443.msg58874670#msg58874670

[pooya87]

for any random public key add,sub.div,multple output is unknow 3rd publickey (x,y)ok,

You can add 2 points (public keys) or subtract them but you can not multiply or divide two points.
You can multiply or divide a point with a number but you can't add or subtract an integer from a point.

Maybe if you explain what you want to achieve with these operations we can help you better.

any one solve this problom i well donate for you 2022$ ==  0.043 current btc price #

Place the 0.043BTC with an escrow and open a new topic in the services board.

[mynonce]

any one solve this problom i well donate for you 2022$ ==  0.043 current btc price #

Place the 0.043BTC with an escrow and open a new topic in the services board.

solved ...

...
iknow random private key: how to find y is small range or big range  atleast guess
...

If you have a private key, you can't know whether your y coordinate is in small range or big range before calculating it.
There is no relationship between your public key y value and your private key. Else you would be able to calculate the private key with the public key.
Or we could say:

... It is impossible ... because then ECDSA would be broken.

As of today 01/01/2022