Yes, you are correct, it was meant to expand the search range, like you said, be able to solve 160.
However, I am pretty sure it had bugs or speed was lost. I'm not sure it he has tinkered with it any more since his original post.
Check out Etar's kangaroo version; it is same as JLPs (but trailing DPs; zeros at the end) but can solve up to 192 bit range.
Hi WanderingPhilospher, thanks for the quick answer
Actually the 256 version is not working, i cloned the code from the Ripo and build it with CUDA 12.3 & sm_86 and tested it with the same example from JeanLucPons
This one
49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000
49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff
0459A3BFDAD718C9D3FAC7C187F1139F0815AC5D923910D516E186AFDA28B221DC994327554CED887AAE5D211A2407CDD025CFC3779ECB9C9D7F2F1A1DDF3E9FF8
0335BB25364370D4DD14A9FC2B406D398C4B53C85BE58FCC7297BD34004602EBEC
The original JeanLucPons Kangaroo took 1:30 to find both minute while this 256 version didn't find anything even after 20 min ... therefore i think its not helpful.
Regarding the Etar's kangaroo .. you mean this one
https://github.com/Etayson/Etarkangaroo ?
I wonder why there is no source code
what do you mean with this "trailing DPs; zeros at the end" can you explain more please
Regards
The source code is there. It's built with PureBasic. Nice, simple, clean code.
DPs can be at the beginning, middle, end.
JLPs DPs (Zeros) are leading, meaning they are at the beginning. I believe Etar's are trailing, at the end.
So JLP DP 20 = 00000xxxxxxx
Etar's DP 20 = xxxxxxx00000
It doesn't matter if they are trailing or leading. Both are good and work.
Test Etar's version out.