Topic: Pollard's kangaroo ECDLP solver - page 132. (Read 55445 times)

Suggested DP for RTX 2080ti is 32, i used 31 because have  some rigs rtx2070 where DP=32 is bit high.
Less DP need much more memory.

Sr. Member or higher? Interesting... DP 31, seems too high.

but this error apear not from start. Program can be launched sometimes without any error. but any way after fiew minutes got this error.
I do not compile programm by self. I use release from github.

Maybe this error associated with pinned memory.
I look at code and didn’t see any unusual instructions there. Only using pinned memory...

maybe somebody want exchange mastersavefile (pazzle #110 (109 bit))  with the same DP size =31 and around the same DP counter and range 2000000000000000000000000000:3FFFFFFFFFFFFFFFFFFFFFFFFFFF? . I have mastersavefile(DP=31, DP Count  : 2755716 2^21.394)
Exchange available only for Sr. Member and higher

That usually means the GPU code was compiled to target a compute capability higher than what your card supports. The GTX 1080 Ti supports up to 6.1, so it would need to be compiled with sm_61,compute_61 or lower.

Who know what is problem can be with 1080ti and Kangaroo.exe
OS: Windows 10, i was tryed different drivers.. allways the same error. 

There should be balance between DP size and GPU perfomance.
Small DP size = more GPU memory = less GPU perfomance, big DP size = more time to find expected amount of DP
And i agree that if you don`t know exist key in this range or not you should not use Kangaroo algorithm.
Kangaroo algorithm used only in case that  you know that key exist in range!

You check 4 keys but if you didn’t find first the other 3 will not start to search now just one by one . If you don’t know range of search it’s impossible to find keys

Hello, everybody.

Does it make sense to continue the test, or is it better to end with ctrl^c and run with other parameters such as-d 22 ? The range is not known, I am looking for approximately up to ^91 inclusive.

1. Is there a chance that a collision will be found in the remaining range (Expected operations: 2^46.56 - [Count 2^45.01 ) ?


2. I have to wait a very long time, please help me-please tell me what settings are better to use ?


Please.




Thanks

Have a nice trip.

Happy holidays!

I will be off up to the end of the next week.
I'll add the support for the -ws for client backup, this should avoid this overhead due to path breaking.
Good luck for solving #110

I need more tests.
I think path breaking (when you are not using -ws) can also impact but I'm not sure.

Maybe i am wrong but it may be better to increase the range by N beginrange-n/2 and endrange +n/2.
This will require twice as much time to search, but it will exclude the option that the key will be at the border and need ~22 times more DP than expected.. no?

I'm not really surpirsed.
The key you search is the worst case.
When searching a key near to the border, you have only one half of tame and wild that overlap.
In that case you need ~22 times more DP than expected, this can happen
If you count the total number of jumps:
Each time you restart from scratch a program (or a client), you have the overhead of nbKangaroo*2^dpbit, this is the average time that each kangqroo produce a DP.
This is why you need an nbKangaroo*2^dpbit the lowest possible compare to sqrt(N).


To improve the search on the border it is possible to have a non uniform sampling and increasing kangaroo density near the border, it compensates a bit.

@Jean_Luc

I performed a small test late last night and the results were quite surprising. So in theory this can happen, unless I’m overlooking something obvious. Please see the output from Run 4, ~43.4(sqrt(N)). I am going to code a very simple version of Pollard’s Kangaroo algorithm to see if this behavior holds.

Run: 1
Run: 2
Run: 3
Run: 4

A question for understanding.

Workfiles can be merge with same Keyspace and same dp numbers and same key for search.

When it's not the same we have to use the - ws Funktion.

And it only make sense merge safe work file from maybe running one day with safe.work1 and secound day with safe.work2

But when we restart the kangaroo process it everytime take new random points but are these random points all saved in one work file or only the last random points what was created?

No there is no feedback yet from the server to kill kangaroos which collide in same herd.
This is tricky to implement but possible.
On the other hand, this kind of collision is rather rare (up to 2sqrt(N) total jumps) and if you start to have too much collisions, it is better to restart all clients in order to re-randomize all starting points.

Does the server perform synchronization with all its clients and kill "looped" kangaroos? Or the server only listens to clients, collect works files and search for collision without feedback to clients?

In order for a collision to happen, one needs at least 1 DP per kangaroo. This is the absolute minimum. In my software (June 26 - July 5, 2019) I was targeting 8 DP/kangaroo at 100% expected jumps. Then my very simple hash table was with max 2³² entries, but DPs were limited to 2²⁹ entries (IIRC 2²⁸ for #95). The whole program was using 48GB for the data - 32GB for DP, 16GB for hash table. For #95 2^27.79 points were used at 86.55%, for #100 2^26.97 at 69.1%. All the DPs were written to file, there was no performance difference on the AWS instance (p3.8xlarge). The file was write-only, since I never needed to read from it, software just found the keys.

In my experiments collision was happening between 3 and 12 DP/kangaroo. There was never tame/tame or wild/wild collision, since I used the original Pollard Kangaroo, no wrapping around 0 or other funky stuff - IMO it would make it faster in half of the cases, and way slower in the other half, when it's negative.

I was using 72*512*256 = 3²2²⁰ kangaroos per GPU. So for #110 if one is using the same number of kangaroos on 128 GPUs, at 8 DP/kangaroo it would be 2^33.17 DPs, or 576GB for DPs, and maybe 128GB for (a not-so-simple) hash table minimum.

The other thing that would affect performance is the bandwidth in server-GPU communication. With 8 DP/kgr at 100% of expected time, one can calculate the DP/second of each client. For #110, 128 GPUs, and 9 million kangaroos/GPU, 42.18 million jumps/kgr for 100% exp. time, 1600 MJ/s per GPU, 172.6 Jumps/second/kangaroo, about 618 DP/GPU/second are needed, which is 39 KB/s without overhead. For 128 GPUs the total bandwidth without overhead would be 5 MB/s, or 40 Mbit/s.

Yes, I set dp=24 because I did not want the solver to complete too fast, dp=18 would be more appropriate.