nope brother
the private key starts with L3
the key ranges you posted private keys start with K
3803496f04b8c0f3e8335eb24b07a4a15335d37bff03bafbb19640a287e0609a
Ky6bKVgbJPFRiAPxvBo4ftiAMkKCBjAbWfVRWEevsHxgULTthBFB
Sorry, I made two mistakes.
First is adding 1 less character (total 51 instead of 52). The correct values are:
Minimum
L39HAHFF1p6vxjBEe4YMxno11111111111111111111111111111
b0bea32711dbb7429ba37464ffbb4c8cda31ea17c6d85d063c0aa4d2c8d5e30f
Maximum
L39HAHFF1p6vxjBEe4YMxnozzzzzzzzzzzzzzzzzzzzzzzzzzzzz
b0bea32711dbb7429ba37464ffbb4c908969f5b84b442e0734743c599dec7459
Diff:
1253753004473247624297767682974128968010 = 1.25E+39 (which is close to your initial value).
Second is that the number I posted is all permutations of the base58 characters if they are placed in their missing positions (ie. 58
29) instead of using the method above since all missing characters are from one place at the end without anything in between.
i can able to recover last or even mid where missing seven to eight or upto 10 in matter of minutes thats not an issue
its more than 10 that whats the issue is i am expermienting on it anyway thanks for your suggestions brother
Up to 12 characters from the end can be recovered very easily since you'd essentially be checking less than a million keys. The problem is that the numbers grow very fast as the number of missing chars increase.
This is wrong:
L39HAHFF1p6vxjBEe4YMxno11111111111111111111111111111
b0bea32711dbb7429ba37464ffbb4c8cda31ea17c6d85d063c0aa4d2c8d5e30f
Maximum
L39HAHFF1p6vxjBEe4YMxnozzzzzzzzzzzzzzzzzzzzzzzzzzzzz
b0bea32711dbb7429ba37464ffbb4c908969f5b84b442e0734743c599dec7459
The correct is:
b0bea32711dbb7429ba37464ffbb4c8cda31ea17c6d85d063c0aa4d2c8d5e30f=L39HAHFF1p6vxjBEe4YMxnnzzzzzzzzzzzzzzzzzzzzzzfskX9dq
b0bea32711dbb7429ba37464ffbb4c908969f5b84b442e0734743c599dec7459=L39HAHFF1p6vxjBEe4YMxnozzzzzzzzzzzzzzzzzzzzzzv62YdrY