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.