Pollard's kangaroo ECDLP solver

[Jean_Luc]

Hi there

@etar
I checked the client and server and I didn't manage to reproduce the issue.
If I break the network at the client side, the server close the connection after the timeout (5min) and when the client goes back it reconnect.
But I will add a http like connection mode and a way to set up the send period.
There is way to do that by setting the CLIENT_TIMEOUT to 3 sec and the SEND period to 10 sec for instance. You get the following output but it works.

Client side:
[180.22 MK/s][GPU 180.22 MK/s][Count 2^29.99][08s][Server     OK]
RecvFromServer(Status): Software caused connection abort
[140.52 MK/s][GPU 140.52 MK/s][Count 2^31.07][18s][Server     OK]
RecvFromServer(Status): Software caused connection abort
[140.34 MK/s][GPU 140.34 MK/s][Count 2^31.68][28s][Server     OK]
RecvFromServer(Status): Software caused connection abort
[141.10 MK/s][GPU 141.10 MK/s][Count 2^32.11][38s][Server     OK]

Server side:
Closing connection with 127.0.0.1:64273
[Client 0][DP Count 2^19.11/2^21.05][Dead 0][41s][19.2/49.5MB]
Closing connection with 127.0.0.1:64274
[Client 0][DP Count 2^19.70/2^21.05][Dead 0][51s][28.0/60.7MB]
Closing connection with 127.0.0.1:64275

@zielar

wow, 460000Mkeys/s, really ? #110 should be solved tomorrow...

[1715476081]

1715476081

[PietCoin97]

Hello Jean Luc

Hope you had nice holiday.

When you will publish a first release for multi pubKey support?

[zielar]

I have currently engaged a total power of 460000Mkeys/s.
#110 I have at the moment [DP Count 2^26.87 / 2^27.55]

The Pollard's kangaroo ECDLP solver needs on average about 2*(2^(109/2)) = 2^55.5 steps to retrieve this private key, with a total power of 460000Mkeys/s =  2^38.8 steps/sec it would take 2^16.7 seconds, about 30 hours.

With the same power, for the key #115 (114 bit) it would take 2^19.2 seconds,  about 170 hours (7 days).

Thank you very much for the specific (as always) conversion of your power into the required time to solve :-)

This is really huge power! ) Is it like 300-400 cards Tesla V100 / GTX 2080ti ?

That's right ... It's the result of combining the power of Tesla V100 and 2080Ti.

wow, 460000Mkeys/s, really ? #110 should be solved tomorrow...

If I really get the solution after reaching 2^27.55 - it will actually happen tomorrow.
At the moment I am on level 2^27.03


Jean_Luc in earlier posts I read that the mechanism that proposes the best DP value to perform the selected task requires refinement, yes?
My question is: what DP value will best be used for #115 for V100 and 2080Ti cards?
I have ~400GB RAM and 2TB of disk space available

[PietCoin97]

@Zielar

do you use this power from your company or have you so much money for rent so much power or do you have miningfarm ?

[MrFreeDragon]

All other developers did not publish the code, but just were trying to sell it.

Yes? Just no one tried to write it! https://bitcointalk.org/index.php?topic=5218972.msg54089243#msg54089243

The code was written and used last year in June-July fore sure. The GPU version helped to solve #100 key.
Here is the post of the guy used his own made GPU Solver in last year: https://bitcointalk.org/index.php?topic=1306983.msg52535752#msg52535752

Here is the example of the code posted last year for sale: https://www.youtube.com/watch?v=kMevZQc7774
And he was selling his code (closed one) for 100-150USD here: https://satoshidisk.com/pay/C9V45V

So, yes. Other developers did not disclose their codes, but just tried to sell it.

The version developed by Jean_Luc is much better than were made earlier. And I believe that Jean_Luc's GPU Solver is the best GPU Solver at the moment.

EDIT: Jean_Luc also started to develop GPU Solver much earlier than your post dated March 2020. He developed BTC Collider in January 2020 as a learning one before GPU Solver: https://github.com/JeanLucPons/BTCCollider/issues/3#issuecomment-578028490

[zielar]

@Zielar

do you use this power from your company or have you so much money for rent so much power or do you have miningfarm ?

V100s - company
2080Ti - private farm

[dextronomous]

first all the luck to zielar, the man's here since way back, one of the early finders of them keys. nice job man,

so just trying to relate to the facts.

jeanluc has written that great software that no one else has done,
and this started on gpu with the alek's version around first of all great thanks to all that,
r e s p e c t

btw anyone using one of these.

Full Cloud Tpu v2 pod more then 200x faster then 1 v100 gpu
TPU v2 Pod is 27 times faster than the machine with 8 NVIDIA Tesla V100 in n1 - standard - 64 Google Cloud VM,
 the total calculation cost is It is 38% lower than that.

[Jean_Luc]

Thanks

Yes my holidays in the mountains was vey good

Jean_Luc in earlier posts I read that the mechanism that proposes the best DP value to perform the selected task requires refinement, yes?
My question is: what DP value will best be used for #115 for V100 and 2080Ti cards?
I have ~400GB RAM and 2TB of disk space available

The best choice should be made taking into account the total number of kangaroos.
You have to choose nbKangaroo*2^(dpbit) the smallest possible comparing to 2^58.5.
If you have 400GB of RAM, choose dpbit to have an expected RAM of 200GB max.

[zielar]

Damn it will hit me soon! The server application is currently restarting every 5 minutes, which means that I start from the same place all the time :/

[Etar]

Damn it will hit me soon! The server application is currently restarting every 5 minutes, which means that I start from the same place all the time :/

-snip-

not from the same place, server just restart kangaroo, all DP points are safe and continue grow.
The larger the DP counter, the slower it counts - this is natural

[zielar]

That's right, but notice that I have a progress record saved to the file every 10 minutes, and the server disconnects every 1-5 minutes so I start from the last dump, so still from the same place.
In addition, I can see that after restart it starts again at 27.22, where there is more before restarting.

[Etar]

That's right, but notice that I have a progress record saved to the file every 10 minutes, and the server disconnects every 1-5 minutes so I start from the last dump, so still from the same place

if server restart every 5 minutes change write interval to 3 minutes. I think for your server it is not a problem.

[Jean_Luc]

Arg,
Hope there is no problem with a file bigger that 4GB !
The last save work printed a wrong size.
Do not restart clients and restart the server without the -w option.

[zielar]

Yes, the dump file currently has 4.64GB and it takes about 30 seconds to reboot when restarting, and about the time it takes to write).
If I set the record every three minutes - it's still 2 minutes of work which significantly increases the time. I am writing about this because to further levels this can be a bothersome problem.
I removed -w from the command line and we'll see what the effect will be.

EDIT:
soooo baaaad...

[Etar]

Arg,
Hope there is no problem with a file bigger that 4GB !
The last save work printed a wrong size.
Do not restart clients and restart the server without the -w option.

I use my version of server client app and do not get shutdown server.
I'm not sure that it will be useful to you with your dp size.
I use DP=31 and for ex. rig 8x2080ti send file 1.6Gb every 2h, rig 6x2070 around 700mb every 2h
with your size DP=28 file should be 8 times more.
Any way if somebody interesting in app i can public here my code for purebasic.(for Windows OS x64)

[Jean_Luc]

@zielar
Did you use the original server or a modified version ?
Could you also do a -winfo on the save28.work ?

[WanderingPhilospher]

Arg,
Hope there is no problem with a file bigger that 4GB !
The last save work printed a wrong size.
Do not restart clients and restart the server without the -w option.

Server is fine. I have over 8GB file that I am reading and rewriting to.

[Etar]

Server is fine. I have over 8GB file that I am reading and rewriting to.

Not for windows. In windows server crashed without any error and randomly in time.
Only if there wiil be 1 connection server don`t crashed.

[WanderingPhilospher]

Server is fine. I have over 8GB file that I am reading and rewriting to.

Not for windows. In windows server crashed without any error and randomly in time.
Only if there wiil be 1 connection server don`t crashed.

All I use is Windows...using the original server/server code from Jean Luc.

[WanderingPhilospher]

Yes, the dump file currently has 4.64GB and it takes about 30 seconds to reboot when restarting, and about the time it takes to write).
If I set the record every three minutes - it's still 2 minutes of work which significantly increases the time. I am writing about this because to further levels this can be a bothersome problem.
I removed -w from the command line and we'll see what the effect will be.

EDIT:
soooo baaaad...

What config is your server? CPU, RAM, etc?