Dealing with Incomplete WIFs

Thought I’d start this convo about WIFs with missing parts. Anyone else dealt with these strange cases? For instance, if I have a public key, I would: - Brute force the first 4 missing characters - Use BSGS to tackle the next 6 missing ones - Combine both methods to solve everything at once. PawGo, maybe this hybrid approach is what you're looking for, just a thought.

The tricky part is definitely the middle characters. Any tweak there messes with the checksum and the compression flag. You should try changing those 6 characters and see if they yield the right flag 01. It’ll help narrow down the possibilities.

True, implementing the right increments could let me crack this in less than 30 mins on CPU. Definitely need to run some tests. Example keys I’m working with: L1dU1111d4NTd71111116zCyXqGyWXhXTa16dNWXZs7cpdk6en2t I’m using BSGS for the 6 missing chars and that part's instant. Might do it faster if I change my approach based on what you said.

I’m looking for a quicker way to find the next valid WIF by checking for the next 01 in the encoded byte. But it seems like it’s more complicated than my current method, so I’m dropping that idea. PawGo, if you’ve got tips on how to do it easier, share please! I’ll post a step-by-step of what I’m doing with my program soon.

I’ve been curious about this too. I based an algorithm on it, but in the end, I figured it wasn’t a guaranteed fix, so I let it go. I tried to find the steps that would yield the correct checksum. But I found it only works for a limited range of missing characters. After that, it’s hit or miss. I had decent results for a couple of characters near the limit but anything further just didn’t work.

Hey, any updates on solving split-keys? Like with this example: L****9****fFfVQU5uie8xmdSisUd8ESWaf956kM8wKAkc48o9nz. Any thoughts on using Kangaroo-stride for this?

Interesting issue here, but I’d break the encoding from key recovery immediately. WIF is just the outer shell. Once you decode it, you’re left with the version byte, the 32-byte private key, maybe a compressed-key marker, and the checksum. A small change in Base58 usually alters the decoded value rather than just flipping a private key byte. If you know the real public key, EC subtraction could help out.