-snip-
Imagine a big bag full of green beans and only one red bean (the private key we're looking for). If I pick a random bean blindly from the bag and throw it back if it is not the red one, every bean I pick will have the same incredibly low probability of being the red one. And for each pick, the chance of getting the red one will be the same as taking the one I threw back before... So I might end up scanning a lot more keys than the size of the range before I find the private key.
So even if I count the number of beans I test, I have no guarantee that after testing as many beans as there are in the bag, there will be no red bean. Maybe I was just unlucky and didn't pick it.
Any constructive thoughts/opinions on this?
I don't think anyone searches for a key this way. Usually, if you want to search randomly, the entire range is divided into small subranges. These subranges are entered into the database. And each time after a random selection of a subrange from all the remaining ones, it is removed from the queue and does not participate in the future. Thus, green beans do not return to the bag.
Hi,
Lately I was wondering if it is possible to modify JLPKangaroo_OW_OT to write DP's on SSD M.2 NVMe instead of RAM? Do You have some experience or theoretical knowledge about such an issue?
I know that RAM is something different than SSD, but concerning that main task in Kangaroo is to caclucate points, find DP's and search for colision, is there a chance to store DP's on NVMe SSD without losing performance?
Best Regards
Damian
For JLP you can try using client/server. The DPs will be saved and sent to the server, where they will be merged into 1 file.
Or if you don't care what software to use, you can try Etarkangaroo where can save DPs after any period of time without losing much in performance. When saving, they merge.