If someone wants to run a solver with small DPs, but the server’s resources don’t allow it, then you can use the -wsplit option,
which appears in version 1.7 of the solver.
But in any case, you must have a PC that can merge files. I just had such a problem.
Now I can safely merge files on my home PC. In order not to do it all manually, you need a grabber and a merger.
File grabber is launched on the server, merger is launched on the home PC.
Merger communicates with the grabber and requests files from him. The graber sends, if any, and then removes them from the server.
The merger, in turn, after receiving the file from the grabber, starts the merge process, during which it is possible to find the key, after merge temp file deleted.
Grabber gives files only to an authorized merger.
If it helps someone, archive with source codes, compiled programs and example .bat files: https://drive.google.com/file/d/1wQWLCRsYY2s4DH2OZHmyTMMxIPn8kdsz
Edit: fixed little memory leak at grabber side.

As before, the sources under Purebasic.
mergeServer(grabber):
mergeClient(merger):

if you still haven't managed to export the workfile, here are the changes I made to the code to export the DPs to txt.

The X-coord is 128+18 bits and distance 126bits. The X-coordinate could be re-generated from the distance if necessary.

https://github.com/PatatasFritas/FriedKangaroo/commit/1669df5f91ef2cc8a7619b21f66883fa164ab602

With the new -wsplit option:

How are you using it?

The way I read, it saves an updated file let's say every -wi 60 seconds. Got it. I've tested it.

So the only way the key can be solved on the server side, is if a collision happens in the current, being worked on, reset/smaller hash table (the one that will be saved next)?

The server doesn't compare the different saved files for a collision, so one must merge the different saved working files to check for a collision.
If you have 10, 20, 30, 100, 1000 saved files over a period of days, weeks, months, are you manually merging the saved work files every so often?
The current merge option only allows the merge of 2 files at a time...manually merging could become an hourly task (depending on how many files you have being saved each minutes/hours.)

So you have a benefit in RAM but increases the amount of work you have to do in merging files?

Grabber and merger merge files in realtime, so i do not have any split files on server. Once file exist merger merge him with masterfile.
all what you need it is set -jobtime to value (wi/2*1000). If -wi set to 60, than you need -jobtime 30000, -jobtime in ms.

how much gpu's you have ?

I think folks are just being impeded by storage and network issues.

could you try this for calc time about your 24 2080ti gpu for 100 bit
0314AA23C847D86CE1FCDC4B3E0524F741FDE2AC4B38B522ED2E3B77CF500D5718
and you can use client server or single system with gpuid 0,1,2,3 to 24 command
and just run and you will have estimate time, could update me your estimate time ?

The estimation for 100bit key with 24x2080ti is approximately 24 hours.

24x2080ti has 29500MJump/sec, so 2^(100/2+1.15) 29500Mjumps/sec --> 24 hours

With my own implementation which is memory optimized (16bytes/point with 22-bit mask), I will consume between ~181GB and ~1.1TB of RAM from best to worst case for a 109-bit interval. If the 110-bit private key challenge hasn’t been solved by @zielar before Sunday night, then I would agree that something is definitely wrong; only assuming that he’s used in excess of 1TB of RAM, otherwise it’s just bad luck.

friendship)