My case is not simple. My key structure is: the first 26 characters are known, then 3 unknown characters, then 5 known characters, then 10 unknown characters, and finally 8 known characters. So I have two gaps that significantly increase the search space.
My WIF [26 known]+[3 unknown]+[5 known]+[10 unknown]+[8 known]
I have already checked more than 80 thousand possible ranges. Since my GPU is a laptop 4060, I can check about 200 ranges (2*65) per hour. Sometimes I also connect rented GPUs — about 15 units of RTX 5070 — to process the bulk of the variants.
You should not approach this by splitting in ranges, your odds of finding the key are very small that way.
What you need is a variation of a Kangaroo-like algorithm which can operate on incomplete WIFs. I didn't look at it super closely yet but is seems doable (assuming you know the public key of the wallet)
I'm happy to help you recover this. I like to think I'm trustworthy enough given the fact that I unlocked millions with 67 and 68 and shared the prize fairly with everyone involved.
Let me know if you're interested, there's quite a bit to code to get there.
First, I want to explain my situation. I partially lost my private key written on paper. Some characters became unreadable, so now I know only parts of the key and have several missing sections. Because of this, I am trying to recover it by searching through the possible combinations.
The structure of my WIF private key looks like this:
[26 known characters] + [3 unknown characters] + [5 known characters] + [10 unknown characters] + [8 known characters]
So there are two missing segments. The first gap is 3 characters, and the second gap is 10 characters. Because of these two gaps, the search space becomes very large.
To explain my approach more clearly, I created a test example.
I generated a test address using the tool:
https://iancoleman.io/bip39/Test address:
1P4DUQSoS6mxKLA7ckNw2N2P5VYiqyXVr5
Public key:
02300f7afaff23e07c2f17181464d9fbdf8ef9060bdd9d781dc7203591d13fee45
Private key (WIF):
KwpcZkhKLZy9opCsWLqUjuKccNMpWV9yVqrXvgcrjTbNz1co9etU
Then I intentionally created the same missing pattern in the private key:
[26 known] + [3 unknown] + [5 known] + [10 unknown] + [8 known]
Next, I generated 200 possible combinations for the first 3 unknown characters. For testing purposes, I inserted the correct 3 characters at the end of the list so that eventually the search should reach the correct variant.
The search logic works like this:
For each possible combination of the 3 unknown characters, I temporarily insert them into the key.
Then I create a search range for the second missing part (the 10 unknown characters).
To define the range:
For the minimum value, I fill the 10 unknown characters with "1111111111".
For the maximum value, I fill them with "zzzzzzzzzz".
This creates a valid range where the real private key must exist.
So instead of brute-forcing everything at once, I only search inside this defined range for each of the possible 3-character combinations. In other words, the search process iterates through the possible prefixes and checks whether the correct private key exists inside that corresponding range.
The total number of combinations for the first missing section is 195112.
So far, I have already checked about 85,000 ranges.
For the search itself I use RCKangaroo (Pollard Kangaroo) by RetiredCoder.
Each range check takes about 30 seconds on my system. Most of that time is spent on initialization before the actual computation begins.
Below is an example of how the terminal output looks during the process:
[Search 0] Try 4423/5631: 'meP' (65.45 bits)
********************************************************************************
* RCKangaroo v3.1 (c) 2024 RetiredCoder *
********************************************************************************
This software is free and open-source:
https://github.com/RetiredCIt demonstrates fast GPU implementation of SOTA Kangaroo method for solving ECDLP
Windows version
CUDA devices: 1, CUDA driver/runtime: 13.1/12.8
GPU 0: NVIDIA GeForce RTX 4060 Laptop GPU, 8.00 GB, 24 CUs, cap 8.9, PCI 1, L2 size: 32768 KB
Total GPUs for work: 1
MAIN MODE
Solving public key
X: 5B23418F548FDF1E797AA39E9C3DFF9E33A80..........................................
................
Y: 8881B40AA828B849C340645E569FC74A17804338765BDE51AF1757D541DCBE7
Offset: 12CC0A316CCC60AE06B93A397A2824FEC7524C3CC666A730001080381321A5AB
Solving point: Range 65 bits, DP 14, start...
SOTA method, estimated ops: 2^32.702, RAM for DPs: 0.203 GB. DP and GPU overheads not included!
Max allowed number of ops: 2^35.287, max RAM for DPs: 0.283 GB
Estimated DPs per kangaroo: 2.891. DP overhead is big, use less DP value if possible!
GPU 0: allocated 458 MB, 147456 kangaroos. OldGpuMode: No
GPUs started...
MAIN: Speed: 1557 MKeys/s, Err: 0, DPs: 935K/426K, Time: 0d:00h:00m/0d:00h:00m
MAIN: Speed: 1575 MKeys/s, Err: 0, DPs: 1888K/426K, Time: 0d:00h:00m/0d:00h:00m
Operations limit reached
Stopping work ...
I use **-dp 14** and **-max 6** so that nothing is missed. I hope this is sufficient.
I really like the speed of the author's program. Earlier I tested another implementation using the same puzzle and the same input data. In that case, the Pollard Kangaroo implementation found the private key in more than 1 hour, while the author's program found it in about 39 minutes.
If I manage to recover my wallet using this program, I will definitely support the author. I honestly don’t know what motivates people like him to spend so much time developing such powerful tools and releasing them for free. But if the program helps me solve my problem, I believe that kind of work definitely deserves a reward.
