missing 18 characters from my wif private key

[notkim]

Hi

i have a old wif key but it only has 34 out of 52 characters
and also address & publickey if that helps somehow.


is there any way i can recover this 

[BitMaxz]

It can recover, but brute-forcing 18 missing characters will take decades even if you have multiple GPUs unless you only have 8 or fewer.

You can try but don't expect to get the exact missing character immediately.
A tool you can use is The FinderOuter

[LoyceV]

It can recover, but brute-forcing 18 missing characters will take decades even if you have multiple GPUs unless you only have 8 or fewer.

It's much faster if the public key is known, and it could be even better if the missing characters are the checksum (at the end of the private key). So OP may be in luck, but I've never actually done this myself.

[notkim]

It can recover, but brute-forcing 18 missing characters will take decades even if you have multiple GPUs unless you only have 8 or fewer.

It's much faster if the public key is known, and it could be even better if the missing characters are the checksum (at the end of the private key). So OP may be in luck, but I've never actually done this myself.

unfortunately its only the first 34 characters . also that FinderOuter seems to only use cpu, so too slow for my 18 lost chars no?

[Cricktor]

You don't understand. It's better for you when you have the first chunk of characters of your WIF than otherwise, because this would limit the range of private keys to search in a much more favourable way (if I don't get it wrong, I haven't had to do such a recovery myself so far, only experimented a bit to gain some knowledge). Um, not sure if my logic holds water here, but I had probably a Gin Tonic too much to think clearly.

What LoyceV mentions is when you have a limited bit-range that needs to be explored and you have a public key exposed and known of that private key, you can use methods like Kangaroo to find the correct private key much faster than a conventional brute-force search in such a range.

Off the top of my head I can't estimate what 17-18 missing trailing characters of the WIF translate to with respect of missing bit-range. IIRC, five of the trailing characters are the embedded checksum, so you're actually missing 12-13 characters of your WIF (WIF private keys are 51 or 52 characters long, Base58check).

Roughly you're missing around a quarter of your private key, if my napkin math is right, let's assume around 65-75 bits, maybe 80 at worst. That's a bit-range size which seems very doable with a modified RCKangaroo solver or similar at very first glance. (I might be wrong as I compare it to the Bitcoin puzzle challenge where limited bit-range private keys have been "easily" broken for ranges below 100 bits with an exposed public key. The last largest bit-range cracked with exposed public key is currently puzzle #130 (129 bits range) but this one took months with thousands of GPUs, IIRC.)

Be careful: users here might promise you they can help and ask for your 34 characters you have. You shouldn't give them away lightly or at all!

[notkim]

You don't understand. It's better for you when you have the first chunk of characters of your WIF than otherwise, because this would limit the range of private keys to search in a much more favourable way (if I don't get it wrong, I haven't had to do such a recovery myself so far, only experimented a bit to gain some knowledge). Um, not sure if my logic holds water here, but I had probably a Gin Tonic too much to think clearly.

What LoyceV mentions is when you have a limited bit-range that needs to be explored and you have a public key exposed and known of that private key, you can use methods like Kangaroo to find the correct private key much faster than a conventional brute-force search in such a range.

Off the top of my head I can't estimate what 17-18 missing trailing characters of the WIF translate to with respect of missing bit-range. IIRC, five of the trailing characters are the embedded checksum, so you're actually missing 12-13 characters of your WIF (WIF private keys are 51 or 52 characters long, Base58check).

Roughly you're missing around a quarter of your private key, if my napkin math is right, let's assume around 65-75 bits, maybe 80 at worst. That's a bit-range size which seems very doable with a modified RCKangaroo solver or similar at very first glance. (I might be wrong as I compare it to the Bitcoin puzzle challenge where limited bit-range private keys have been "easily" broken for ranges below 100 bits with an exposed public key. The last largest bit-range cracked with exposed public key is currently puzzle #130 (129 bits range) but this one took months with thousands of GPUs, IIRC.)

Be careful: users here might promise you they can help and ask for your 34 characters you have. You shouldn't give them away lightly or at all!

hello,

so since i have the first 34 chars and the public key, i could use rckangaroo if i understand right. because i can short the bit range by a lot . but how ?


i put a 1 in the missing parts and then
i did exactly what this web said : https://en.bitcoin.it/wiki/Wallet_import_format
and also make one for z (example L14Cf...zzz). is this right ?

now i have two long hex chars , i checked in what bit range those two hexare like where the value changes and its 80 bits.
so could i just input the small right part of the first hex and use it as start range no?

[nc50lc]

now i have two long hex chars , i checked in what bit range those two hexare like where the value changes and its 80 bits.
so could i just input the small right part of the first hex and use it as start range no?

That should work,
I even reproduced that using a sample WIF with omitted 18characters and my CPU finished it with 55mKeys/s in just 4min 28 sec.

Partial private key: KxnFYf7tBNgaLd4GChPktcLUSceMp37M7t
Decode to hex with min/max padding:

KxnFYf7tBNgaLd4GChPktcLUSceMp37M7t111111111111111111
802e93dc28477c67aa3810d11e657792d33f61fbf26228c59fe19d1bb9c424f69294591c0000
KxnFYf7tBNgaLd4GChPktcLUSceMp37M7tzzzzzzzzzzzzzzzzzz
802e93dc28477c67aa3810d11e657792d33f61fbf26228c5a299f55cb5e18f3e9d7c533fffff

Kangaroo inFile:

Code:

2e93dc28477c67aa3810d11e657792d33f61fbf26228c59fe19d1bb9c424f692
2e93dc28477c67aa3810d11e657792d33f61fbf26228c5a299f55cb5e18f3e9d
02fa7119cc8e246466ec38a9cd8e3e96e61746594452bc95bfb6511af46b6cb86d

Here's the terminal log:

Code:

kangaroo -o kangaroo-34char_test-result.txt kangaroo-34char_test.txt
Kangaroo v2.2
Start:2E93DC28477C67AA3810D11E657792D33F61FBF26228C59FE19D1BB9C424F692
Stop :2E93DC28477C67AA3810D11E657792D33F61FBF26228C5A299F55CB5E18F3E9D
Keys :1
Number of CPU thread: 12
Range width: 2^66
Jump Avg distance: 2^32.97
Number of kangaroos: 2^13.58
Suggested DP: 16
Expected operations: 2^34.10
Expected RAM: 22.7MB
DP size: 16 [0xFFFF000000000000]
SolveKeyCPU Thread 11: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos
SolveKeyCPU Thread 4: 1024 kangaroos
SolveKeyCPU Thread 6: 1024 kangaroos
SolveKeyCPU Thread 7: 1024 kangaroos
SolveKeyCPU Thread 5: 1024 kangaroos
SolveKeyCPU Thread 2: 1024 kangaroos
SolveKeyCPU Thread 9: 1024 kangaroos
SolveKeyCPU Thread 10: 1024 kangaroos
SolveKeyCPU Thread 8: 1024 kangaroos
SolveKeyCPU Thread 3: 1024 kangaroos
SolveKeyCPU Thread 1: 1024 kangaroos
[55.54 MK/s][GPU 0.00 MK/s][Count 2^33.60][Dead 1][04:27 (Avg 05:30)][8.0/27.1MB]
Done: Total time 04:28

Just to make sure, are those long hex characters 32Bytes long (64 characters)?
If so, you're in the right track.

[Cricktor]

Nice testing, nc50lc! Apparently doesn't even need a modified Kangaroo solver. Which one did you use?

That went smoother than my foggy brain could anticipate yesterday. And speed is also quite remarkable, even when only running on CPU (you had 12 cores/threads at your disposal), so no beefy equipment needed if one is patient. It's actually scary fast.

To notkim: I would also recommend to perform a test with a known solution similar to what nc50lc did, so that you can check that your toolset is working good enough to be able to find a solution, before you tackle your incomplete private key.

[notkim]

now i have two long hex chars , i checked in what bit range those two hexare like where the value changes and its 80 bits.
so could i just input the small right part of the first hex and use it as start range no?

That should work,
I even reproduced that using a sample WIF with omitted 18characters and my CPU finished it with 55mKeys/s in just 4min 28 sec.

Partial private key: KxnFYf7tBNgaLd4GChPktcLUSceMp37M7t
Decode to hex with min/max padding:

KxnFYf7tBNgaLd4GChPktcLUSceMp37M7t111111111111111111
802e93dc28477c67aa3810d11e657792d33f61fbf26228c59fe19d1bb9c424f69294591c0000
KxnFYf7tBNgaLd4GChPktcLUSceMp37M7tzzzzzzzzzzzzzzzzzz
802e93dc28477c67aa3810d11e657792d33f61fbf26228c5a299f55cb5e18f3e9d7c533fffff

Kangaroo inFile:

Code:

2e93dc28477c67aa3810d11e657792d33f61fbf26228c59fe19d1bb9c424f692
2e93dc28477c67aa3810d11e657792d33f61fbf26228c5a299f55cb5e18f3e9d
02fa7119cc8e246466ec38a9cd8e3e96e61746594452bc95bfb6511af46b6cb86d

Here's the terminal log:

Code:

kangaroo -o kangaroo-34char_test-result.txt kangaroo-34char_test.txt
Kangaroo v2.2
Start:2E93DC28477C67AA3810D11E657792D33F61FBF26228C59FE19D1BB9C424F692
Stop :2E93DC28477C67AA3810D11E657792D33F61FBF26228C5A299F55CB5E18F3E9D
Keys :1
Number of CPU thread: 12
Range width: 2^66
Jump Avg distance: 2^32.97
Number of kangaroos: 2^13.58
Suggested DP: 16
Expected operations: 2^34.10
Expected RAM: 22.7MB
DP size: 16 [0xFFFF000000000000]
SolveKeyCPU Thread 11: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos
SolveKeyCPU Thread 4: 1024 kangaroos
SolveKeyCPU Thread 6: 1024 kangaroos
SolveKeyCPU Thread 7: 1024 kangaroos
SolveKeyCPU Thread 5: 1024 kangaroos
SolveKeyCPU Thread 2: 1024 kangaroos
SolveKeyCPU Thread 9: 1024 kangaroos
SolveKeyCPU Thread 10: 1024 kangaroos
SolveKeyCPU Thread 8: 1024 kangaroos
SolveKeyCPU Thread 3: 1024 kangaroos
SolveKeyCPU Thread 1: 1024 kangaroos
[55.54 MK/s][GPU 0.00 MK/s][Count 2^33.60][Dead 1][04:27 (Avg 05:30)][8.0/27.1MB]
Done: Total time 04:28

Just to make sure, are those long hex characters 32Bytes long (64 characters)?
If so, you're in the right track.

hello,

so i tested it with the same partial key you have there and it works.
my hex is 64 characters long yes.
now i did the same but with my key and it is still searching, and have no idea why it didnt find it yet even though the estimate time is passed alredy*.
i used this to start (x and y i covered up) :

Code:

./RCKangaroo -pubkey x -start y -dp 16 -range 90 
MAIN: Speed: 9631 MKeys/s, Err: 0, DPs: 2219588K/617401K, Time: 0d:04h:11m/0d:01h:10m

ty

[nc50lc]

so i tested it with the same partial key you have there and it works.
-snip-
now i did the same but with my key and it is still searching, and have no idea why it didnt find it yet even though the estimate time is passed alredy*.

At least we know that there's nothing wrong with your command since my example works with it.
So the issue is in the data that's provided in the command.

You can try to expand the min/max of the hex private key where the rest of the non-matching characters are all 0x00 for -start and 0xff for the -end.
Might have been an edge-case where it's lower than the indicated start range.

E.g.: in my example, instead of:

2e93dc28477c67aa3810d11e657792d33f61fbf26228c59fe19d1bb9c424f692
2e93dc28477c67aa3810d11e657792d33f61fbf26228c5a299f55cb5e18f3e9d

Expand it to:

2e93dc28477c67aa3810d11e657792d33f61fbf26228c5000000000000000000
2e93dc28477c67aa3810d11e657792d33f61fbf26228c5ffffffffffffffffff

Also, make sure that the pubKey is the actual pair of that privKey.

Which one did you use?

It's: github.com/JeanLucPons/Kangaroo

[ABCbits]

Partial private key: KxnFYf7tBNgaLd4GChPktcLUSceMp37M7t
Decode to hex with min/max padding:

KxnFYf7tBNgaLd4GChPktcLUSceMp37M7t111111111111111111
802e93dc28477c67aa3810d11e657792d33f61fbf26228c59fe19d1bb9c424f69294591c0000
KxnFYf7tBNgaLd4GChPktcLUSceMp37M7tzzzzzzzzzzzzzzzzzz
802e93dc28477c67aa3810d11e657792d33f61fbf26228c5a299f55cb5e18f3e9d7c533fffff

I just tried guide you shared with different WIF and it works. But what tool did you use to convert the WIF to HEX? Some online tool refuse to make conversion because the padded WIF have invalid checksum, so i used https://learnmeabitcoin.com/technical/keys/private-key/wif/.

[nc50lc]

-snip-

I just tried guide you shared with different WIF and it works. But what tool did you use to convert the WIF to HEX? Some online tool refuse to make conversion because the padded WIF have invalid checksum, so i used.

It's probably because the decoder tool that you've used is specifically for "Base58Check" which calculates the checksum.
I've used a generic "Base58" tool that basically decodes it to Hex.
(and probably an issue if the correct private key is in the lower/higher range than the result)

[Cricktor]

Code:

./RCKangaroo -pubkey x -start y -dp 16 -range 90 
MAIN: Speed: 9631 MKeys/s, Err: 0, DPs: 2219588K/617401K, Time: 0d:04h:11m/0d:01h:10m

Pretty decent speed... you seem to have a beefy GPU.

I haven't used RCKangaroo much, only few tests and it's a bit ago. As I'm only following the Bitcoin puzzle from an academic perspective, I didn't play much with it.

I wonder if you're correct with the range parameter. Are you sure your search bit-range is 90 bit large, that's quite a lot? Of course only you can determine if it's actually that large.

From nc50lc's example I manually calculated roughly a range of 72 bits, when I counted 18 hex digits for his range, though if I read it correctly from the output of his JLP Kangaroo, it determined a range of 66 bits?

[Cricktor]

Bumping the topic with a question I have for OP notkim (you don't need to disclose any details, I'm not trying to convince you to it).

1. Are you 100% sure, you're using the correct range size and public key?
There must be coins spent from the address that belongs to your partial private key to have the public key exposed. A signed Bitcoin message having used the private key would've exposed the public key, too.

I assume, you know what you're doing and you know how to get the correct public key.


If you have to stop RCKangaroo or it crashes due to memory exhaustion, you may consider to try a fork which seems more memory safe and saves progress checkpoints more often. I assume, it's possible to safely stop it without loosing prior search work on a larger search region.

Disclaimer: I haven't audited the code and I haven't used the tool so far.

See this post by user pscamillo with links to his Github: https://bitcointalk.org/index.php?topic=1306983.msg66599418#msg66599418

[notkim]

hello there,

i was finally able to recover it, i just had a typo in one of the wif characters somehow xd.
So thanks for the help from all of u 

[Cricktor]

...

Awesome and thank you for the update. Good to know it worked out for you.

Can you keep this topic open as I would like to give another user an example of how to find a private key with this method and his case is of similar search range size as yours?

...

Here's an example with 17 missing trailing WIF (compressed) characters.

This is the example private key (known solution as reference)

Code:

KwcqwXrpWbsw2SpPcm6mfcabFhnmafmPGoPbLrscFCCW7kUEG6xr --- WIF Base58check
0BE69F479D2DFBB65ACD0165963E1460912517953702CA45EE2D7868F266F30F --- Hex

I derived the public key with help of bitaddress.org (Wallet Details section)

Code:

03A76A27DE01CCBDFC2A8F9BD9B2DC9C1030AE219E9B13D112EEE5F85A71373F9D

Cutting away 17 trailing WIF characters gives us the following search region in terms of WIF Base58

KwcqwXrpWbsw2SpPcm6mfcabFhnmafmPGoPbLrscFCCW7kUEG6xr  original
KwcqwXrpWbsw2SpPcm6mfcabFhnmafmPGoP11111111111111111  start range Base58
KwcqwXrpWbsw2SpPcm6mfcabFhnmafmPGoPzzzzzzzzzzzzzzzzz  end range Base58


I use the Base58<->Hex conversion tool from https://learnmeabitcoin.com/technical/keys/base58/; for a real recovery case you would need to check if this web tool can also run offline or find or program an offline tool!

Talkimg.com is currently non-functional, I will add pics later working again:


I get this Base58-->Hex from the start and end range Base58
800be69f479d2dfbb65acd0165963e1460912517953702ca45e7119b153c0690a9860dac0000
800be69f479d2dfbb65acd0165963e1460912517953702ca45f313209dfebd5cf0551665ffff
The hex search range bounds from the Base58 are underlined, difference region is highlighted in green.

I deliberately adjusted the hex search range bounds for the JLP Kangaroo input file like this:

Code:

0be69f479d2dfbb65acd0165963e1460912517953702ca45e000000000000000
0be69f479d2dfbb65acd0165963e1460912517953702ca45ffffffffffffffff
03A76A27DE01CCBDFC2A8F9BD9B2DC9C1030AE219E9B13D112EEE5F85A71373F9D

I ran JLP Kangaroo in a VM on 2 cores with 8GB RAM on an Intel Core i5-4300M @ 2.6GHz CPU, that's not the beefiest gear, but still solves the problem in a quite reasonable time...

Code:

Kangaroo.exe -o output17.txt input17.txt
Kangaroo v2.2
Start:BE69F479D2DFBB65ACD0165963E1460912517953702CA45E000000000000000
Stop :BE69F479D2DFBB65ACD0165963E1460912517953702CA45FFFFFFFFFFFFFFFF
Keys :1
Number of CPU thread: 2
Range width: 2^61
Jump Avg distance: 2^30.03
Number of kangaroos: 2^11.00
Suggested DP: 16
Expected operations: 2^31.59
Expected RAM: 13.9MB
DP size: 16 [0xFFFF000000000000]
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos
[9.13 MK/s][GPU 0.00 MK/s][Count 2^31.39][Dead 0][05:51 (Avg 05:55)][3.3/10.1MB]
Done: Total time 05:52

output17.txt reads

Code:

Key# 0 [1S]Pub:  0x03A76A27DE01CCBDFC2A8F9BD9B2DC9C1030AE219E9B13D112EEE5F85A71373F9D 
       Priv: 0xBE69F479D2DFBB65ACD0165963E1460912517953702CA45EE2D7868F266F30F 

The found private key just misses one leading zero char to pad it to 64-hex chars.

With my measly laptop CPU I limited the example to 17 missing trailing chars which took nearly six minutes to solve. Still OK, no beefy GPU needed for this example.


Post edit:
added picture now that talkimg.com is working properly for image uploads again (was down on Sunday)

[Cricktor]

@notkim, because you solved your recovery case, you can close this topic now.

citramonb's case has been cut out by a moderator and moved into a separate topic.