Compressed hex private key with 66 characters?

[NotATether]

Hi guys, I happened upon a private key hex while I was decoding a compressed (beginning with L) base58 WIF 52 characters long, that starts with 80 f3 and is 76 hex chars long.

I proceeded with removing the 8 checksum bytes at the end and this left me 68 hex chars, when the 80 at the beginning was removed I got 66 hex chars of a private key beginning with f3.

But I don't think the length is right, no? Private keys are supposed to be 64 hex characters long not 66. Is the F3 some kind of magic byte of sorts?

EDIT: it begins with 80 f3 not 80 fe.

[1715660656]

1715660656

[1715660656]

1715660656

[1715660656]

1715660656

[1715660656]

1715660656

[PawGo]

Hi guys, I happened upon a private key hex while I was decoding a compressed (beginning with L) base58 WIF 52 characters long, that starts with 80 f3 and is 76 hex chars long.

I proceeded with removing the 8 checksum bytes at the end and this left me 68 hex chars, when the 80 at the beginning was removed I got 66 hex chars of a private key beginning with f3.

But I don't think the length is right, no? Private keys are supposed to be 64 hex characters long not 66. Is the F3 some kind of magic byte of sorts?

EDIT: it begins with 80 f3 not 80 fe.

what about '01' at the end, which indicates compressed WIF?

https://learnmeabitcoin.com/technical/wif

[NotATether]

what about '01' at the end, which indicates compressed WIF?

https://learnmeabitcoin.com/technical/wif

OK that makes sense. The position where there was supposed to be the compression byte and checksum, and a small part of the privkey hex, is messed up because that portion of the private key was lost. I am trying to brute force the end of this guy's missing key.

So I should chop off another two hex chars at the end too.

What do you have? WIF without ending?

Bingo.

[PawGo]

what about '01' at the end, which indicates compressed WIF?

https://learnmeabitcoin.com/technical/wif

OK that makes sense. The position where there was supposed to be the compression byte and checksum, and a small part of the privkey hex, is messed up because that portion of the private key was lost. I am trying to brute force the end of this guy's missing key.

So I should chop off another two hex chars at the end too.

Exactly.
What do you have? WIF without ending?
Let me know if https://github.com/PawelGorny/WifSolver would help.

[NotATether]

@PawGo, slightly off topic but is your solver multithreaded? Default config is only using one thread on my machine.

[PawGo]

@PawGo, slightly off topic but is your solver multithreaded? Default config is only using one thread on my machine.

I think END is for single thread only, try to launch it with SEARCH, it is multithreaded.
How many characters are missing? Maybe this weekend I will add multithreading to END, to be honest I never had a serious case for it, so I was too lazy to do it for myself

Anyway, if only end is missing and you are sure about the part you decoded, maybe bitcrack would be a better solution.

[NotATether]

@PawGo, slightly off topic but is your solver multithreaded? Default config is only using one thread on my machine.

I think END is for single thread only, try to launch it with SEARCH, it is multithreaded.
How many characters are missing? Maybe this weekend I will add multithreading to END, to be honest I never had a serious case for it, so I was too lazy to do it for myself

Anyway, if only end is missing and you are sure about the part you decoded, maybe bitcrack would be a better solution.

I'm missing 11 characters, but End mode is only putting 7 characters at the end of each private key. This has to be a bug, because these keys can't be imported because their format is invalid.

[PawGo]

@PawGo, slightly off topic but is your solver multithreaded? Default config is only using one thread on my machine.

I think END is for single thread only, try to launch it with SEARCH, it is multithreaded.
How many characters are missing? Maybe this weekend I will add multithreading to END, to be honest I never had a serious case for it, so I was too lazy to do it for myself

Anyway, if only end is missing and you are sure about the part you decoded, maybe bitcrack would be a better solution.

I'm missing 11 characters, but End mode is only putting 7 characters at the end of each private key. This has to be a bug, because these keys can't be imported because their format is invalid.

The idea is that I ignore last 4 characters and do not process them - because checksum part could be 'generated' based on decoded existing part. In other words - I prepare partial WIF (without checksum - in my version 4, but I think it could be 5 characters), I add any "stupid" characters just to have 52, I decode it ignoring incorrect checksum and encode again, receiving WIF with correct checksum this time.

This part:

Code:

for (int m = 0; m < missing; m++) {
            sb.append("1");
        }
        byte[] bytes = Base58.decode(sb.toString());
        bytes = Arrays.copyOfRange(bytes, 1, bytes.length - 4);
        if (len == Configuration.COMPRESSED_WIF_LENGTH) {
            bytes[32] = 1;
        }
        String encoded = Base58.encodeChecked(128, bytes);

Later I process this WIF.
Of course it could be optimized somehow, like extract private key and test it as a key, not as a WIF, but as I said - I was never focused on this worker, so I kept it simple.

[NotATether]

This part:

Code:

for (int m = 0; m < missing; m++) {
            sb.append("1");
        }
        byte[] bytes = Base58.decode(sb.toString());
        bytes = Arrays.copyOfRange(bytes, 1, bytes.length - 4);
        if (len == Configuration.COMPRESSED_WIF_LENGTH) {
            bytes[32] = 1;
        }
        String encoded = Base58.encodeChecked(128, bytes);

Later I process this WIF.
Of course it could be optimized somehow, like extract private key and test it as a key, not as a WIF, but as I said - I was never focused on this worker, so I kept it simple.

I'm not in the mood to tinker with Java code at the moment and since this basically breaks wallet importing for me can you make a patch to add the checksum characters in return for about 1% of the address reward sent to your donation address if LostWord manages to find it? (It's a 1.2BTC address, I'll ask him if he's ok with that)

As far as finding privkeys goes it is certainly working better than BitCrack or FinderOuter  

(why previous post was deleted?)

I guess because it was extremely short https://loyce.club/archive/posts/5685/56853763.html

[PawGo]

I'm not in the mood to tinker with Java code at the moment and since this basically breaks wallet importing for me can you make a patch to add the checksum characters

Done in version https://github.com/PawelGorny/WifSolver/releases/tag/v0.5.1
And multithreaded processing ;-)

(why previous post was deleted?)