Did you read his GitHub? He has ranges and keys to benchmark your speed.
And just because you could solve 120 in say a day, doesn’t mean you could solve 125 in 32 days. If the key is in the beginning of the range, before 120s, in relation, you’d solve faster than 32 days. If it was after, then more than 32 days.
Keep it easier,
If a key in the 120 bit range was in the 8s and it took you one day, if 124s key was in the Fs, it would take you longer than 16 days. Make sense?
To give a better, worse case scenario, determine your speed, then calculate time taken by taking the last possible check in a range, (based on how large your baby step file is) and divide it by your speed.
Yes, I've been reading the README, the code, and the description of the algorithm on wikipedia and other publications. I can't yet connect all the dots, but this helps, thanks!
So, is the
n parameter the size of the range "chunk" you are looking at one at a time per thread (still unsure what
k does)?