Hi all, Alberto,
Has anyone done tests of KeyHunt (and shared the results) with very large amount of ram - say 512GB - 1TB? I'm thinking of doing this myself to at least document the speed gains (relationship between the n and k values, and the speed reported). To my understanding, adding more ram will significantly increase the speed because you can use a higher n and k values. I believe adding more RAM is much more beneficial to adding more CPU power, but of course both are important.
Edit: I'm talking about BSGS mode, of course.

Please delete this if it's off-topic for this thread.

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)?

Thanks Alberto, this is indeed what I was missing. I'm trying to understand the exact purpose of the n and k parameters of keyhunt. Is n in this case the number of pre-calculated keys? I'm trying to understand the efficiency of the algorithm - how long it would take to finish a full scan of a given range. Is it as simple as range size (keys) divided by speed (keys/s reported by keyhunt)? I'm assuming not, since this is not a brute-force algorithm.

Every fifth range is 32 (2⁵) times bigger than the last (e.g. the range for #130 has 32x more keys than the one for #125). If I could benchmark my system on how fast it could solve a simpler BSGS puzzle (say #125), how do I extrapolate on how fast it would do with #130? I assume it's faster than 32x the time it takes for #125.


You can build a bot that monitors the mempool (pending transactions) to make sure that there's no one else trying to send your BTC to another address (since they can easily calculate the private key once you publish your transaction). If anyone else is trying to do that, you can send another transaction with a higher fee to out-bid the other parties, but this can create a vicious cycle where no one wins because you all keep increasing the fee for your own transactions until nothing is left.

Hi All,

I've been reading this and other related topics for a few weeks and I'm trying to understand the complexity of the different algorithms and approaches.

For Pollard's Kangaroo algorithm, someone gave an estimate of 2^66.05 operations needed for solving #130 ( https://bitcointalk.org/index.php?topic=5244940.2740 not sure how they reached this conclusion, but from reading about the algorithm it has a similar complexity to BSGS). This equals ~7.6x10¹⁹ operations needed.
For BSGS, from reading about it, is has a complexity of O(n^1/2). Taking the square root of the range (2¹³⁰ - 2¹²⁹ - 1) equals ~2.6x10¹⁹ operations needed.

Is this correct? Is BSGS more efficient, or is it just a wrong way of calculating the efficiency?
I think I'm missing something in estimating the total "operations needed" for these algorithms. Is there a better/correct way of doing this?
Edit: -> Reading keyhunt's documentation, it says it can easily reach the speed of several peta-keys per second (10¹⁸), so I'm definitely missing something...


Considering HW limitations, I am still not familiar with how different Kangaroo implementations work, I see that the JeanLucPons' based on VanitySearch requires GPU power (I assume more cores means better, but not sure what is the requirement for VRAM, CPU, RAM).
For BSGS, seems like keyhunt is the best, and works better with more RAM and more CPU cores.
Am I missing anything? Are there any other/better tools available for searching the ranges with known public keys?