hi @BitCrack
Will you consider releasing a server-client version of bitcrack ?
Will you consider releasing a server-client version of bitcrack ?
Yes, I have been working on it for a little while.
Topic: Pollard's kangaroo ECDLP solver - page 90. (Read 60654 times)
Yes, I have been working on it for a little while.
hi @BitCrack
Will you consider releasing a server-client version of bitcrack ?
Will you consider releasing a server-client version of bitcrack ?
@Jean Luc
If I solved a key at the 100 bit range and I want to reuse the dp file generated from that search, how do I reuse it to search for another pubkey in the exact same range and using the exact same dp?
If I solved a key at the 100 bit range and I want to reuse the dp file generated from that search, how do I reuse it to search for another pubkey in the exact same range and using the exact same dp?
You just merge the file, but at the moment you will take benefit only from old tames.
Yes that's normal, the kangaroo counter works fine the first time and when a reconnection happens, the counter is not incremented again but the kangaroo are there. When a reconnection happens, the server does not display new connection.
I will fix this ASAP, it is just a display bug.
10 reflects the number of clients which have send DP in the last hour.
You can work around this by changing in Constant.h the IDLE timeout.
The important thing to check is the production of DP using -winfo on the server workfile(s).
Ok, I will do that. Yes, the DPs were still accumulating but that would happen whether it was 10 clients or 6. I will fix this ASAP, it is just a display bug.
10 reflects the number of clients which have send DP in the last hour.
You can work around this by changing in Constant.h the IDLE timeout.
Code:
// Timeout before closing connection idle client in sec
#define CLIENT_TIMEOUT 3600.0
#define CLIENT_TIMEOUT 3600.0
The important thing to check is the production of DP using -winfo on the server workfile(s).
I'm just glad it is still working as designed. I left it alone and letting it ride for now.
Thank you for the quick response!
Yes that's normal, the kangaroo counter works fine the first time and when a reconnection happens, the counter is not incremented again but the kangaroo are there. When a reconnection happens, the server does not display new connection.
I will fix this ASAP, it is just a display bug.
10 reflects the number of clients which have send DP in the last hour.
You can work around this by changing in Constant.h the IDLE timeout.
The important thing to check is the production of DP using -winfo on the server workfile(s).
I will fix this ASAP, it is just a display bug.
10 reflects the number of clients which have send DP in the last hour.
You can work around this by changing in Constant.h the IDLE timeout.
Code:
// Timeout before closing connection idle client in sec
#define CLIENT_TIMEOUT 3600.0
#define CLIENT_TIMEOUT 3600.0
The important thing to check is the production of DP using -winfo on the server workfile(s).
Ah Ok, the timeout for idle client is 1hour, after the connection is closed. However when the client will send new DP, the connection is restored.
@Jean Luc...so I was running a longer test today. Same thing happened, started with 10 clients and a few hours in I dropped down to 6, and server says "closing connection..." but then it's back up to 10 clients but Kangaroo power does not reflect that of original kangaroo power. Example, if I started out with 10 clients and 2^25 kangaroos, it dropped to 6 clients, back up to 10 but now only 2^18. Why is that? Also, server does not state "client connecting..." the client number just goes back up to 10. Should I just let it be?edit: I checked client side and it says server ok, but I can see where it stopped with this error: "The operation timed out"
Thoughts?
-snip-
I don't know so I'm not disagreeing with you but why would you need to cut any tame or wild out?
Same range, only thing changing would be what x coord to look for and compare for solution, right?
here is my reconstructor https://drive.google.com/file/d/1zHwoVjIvYhpgcTy_4sWin_A-3GMiTs5BI don't know so I'm not disagreeing with you but why would you need to cut any tame or wild out?
Same range, only thing changing would be what x coord to look for and compare for solution, right?
when you will first time reconstruct workfile use -checkdp 1 in bat file.
After few persent(or fraction of persent) of job if there will be ok and you don`t get any eror message then close reconstructor> set -checkdp 0> and launch again.
-checkdp 1 need only to see if wild DPs tamed in correct way.
param newpubkey use without prefix 04
If you will see error with -checkdp 1 than previousprivkey set invalid and recocosntructed wild DP has x-coordinate not the same as in source.
Source file not changed during reconstruction.. All DPs going to new work file.
After end of reconstruction you will see somesing like this:
Code:
100.00%
DP count :240568
HT max :8[@ 01D30E]
HT min :0[@ 000001]
Tame count :120410
Wild count :120158
NumberOfWalk:0000000000000000
------------------------
TAME [120410]
TAMED [120158]
SKIPED[0]
TOTAL TAME[240568]
Edit: if you not tamed your wild DPs they are useless to search new pubkeys, just DP count :240568
HT max :8[@ 01D30E]
HT min :0[@ 000001]
Tame count :120410
Wild count :120158
NumberOfWalk:0000000000000000
------------------------
TAME [120410]
TAMED [120158]
SKIPED[0]
TOTAL TAME[240568]
only memory is used, but there is no sense from them.
It is possible that they will lead to incorrect collisions if not tamed.
https://github.com/brichard19/eclambda
Can anyone try my tool on a 2080ti? On a 2080S it gets around 1300MKeys/sec when using 24-bit DP.
Can anyone try my tool on a 2080ti? On a 2080S it gets around 1300MKeys/sec when using 24-bit DP.
I tried your tool (DP18) on a V100.
Code:
[2020-06-22.11:35:35] [Info] DP: 0 TP: 0 853.74 Mpt/s (64 iter/s)
[2020-06-22.11:35:37] [Info] Verifying 40336 results
[2020-06-22.11:35:45] [Info] DP: 0 TP: 0 992.50 Mpt/s (75 iter/s)
[2020-06-22.11:35:48] [Info] Verifying 40362 results
[2020-06-22.11:35:55] [Info] DP: 0 TP: 0 991.18 Mpt/s (75 iter/s)
[2020-06-22.11:35:37] [Info] Verifying 40336 results
[2020-06-22.11:35:45] [Info] DP: 0 TP: 0 992.50 Mpt/s (75 iter/s)
[2020-06-22.11:35:48] [Info] Verifying 40362 results
[2020-06-22.11:35:55] [Info] DP: 0 TP: 0 991.18 Mpt/s (75 iter/s)
Kangaroo on a server too, configured in the same way, however, it is not clear how many kangaroo are running in parallel with your program and what grid setting is used.
Code:
GPU: GPU #0 Tesla V100-PCIE-16GB (80x64 cores) Grid(160x128) (207.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^21.32 kangaroos [11.2s]
[2000.07 MK/s][GPU 2000.07 MK/s][Count 2^37.48][01:52][Server OK]
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^21.32 kangaroos [11.2s]
[2000.07 MK/s][GPU 2000.07 MK/s][Count 2^37.48][01:52][Server OK]
It says exactly how many kangaroos are running in parallel, 58,395,776 in this example:
Code:
eclambda --name testjob85 --gpu-mem-usage 0.9 --device 2
______ ______ __ ___ __ ___ ____ ____ ___
/ ____// ____/ / / / | / |/ // __ ) / __ \ / |
/ __/ / / / / / /| | / /|_/ // __ |/ / / // /| |
/ /___ / /___ / /___ / ___ | / / / // /_/ // /_/ // ___ |
/_____ / \____/ /_____//_/ |_|/_/ /_//_____//_____//_/ |_|
EC LAMBDA CLIENT
VERSION 1.1.1 ALPHA
[2020-06-22.16:26:33] [Info] Connecting to 127.0.0.1
[2020-06-22.16:26:34] [Info] Target public key:
[2020-06-22.16:26:34] [Info] X:F1367CC260779F7EA6C7E4B7258A4D31A4C41D6282C5200571CE10E748A4AADE
[2020-06-22.16:26:34] [Info] Y:0743F0CA057C7F39A9D9A20D4A93555B19F712920EEEF2F267466A2F3D08662E
[2020-06-22.16:26:34] [Info] Distinguisher: 24 bits
[2020-06-22.16:26:34] [Info] Sending results to server every 10 minutes
[2020-06-22.16:26:34] [Info] Initializing GeForce RTX 2080 SUPER
[2020-06-22.16:26:34] [Info] Compiling OpenCL kernels...
[2020-06-22.16:26:34] [Info] Initializing...
[2020-06-22.16:27:09] [Info] Generating 58,395,776 starting points (7184.1MB)
[2020-06-22.16:27:37] [Info] 10.0%
[2020-06-22.16:27:42] [Info] 20.0%
[2020-06-22.16:27:48] [Info] 30.0%
[2020-06-22.16:27:50] [Info] 40.0%
[2020-06-22.16:27:50] [Info] 50.0%
[2020-06-22.16:27:50] [Info] 60.0%
[2020-06-22.16:27:51] [Info] 70.0%
[2020-06-22.16:27:51] [Info] 80.0%
[2020-06-22.16:27:52] [Info] 90.0%
[2020-06-22.16:27:52] [Info] 100.0%
[2020-06-22.16:27:54] [Info] Refilling GPU cache (319.3MB)
[2020-06-22.16:27:54] [Info] 10.0%
[2020-06-22.16:27:54] [Info] 20.0%
[2020-06-22.16:27:55] [Info] 30.0%
[2020-06-22.16:27:55] [Info] 40.0%
[2020-06-22.16:27:55] [Info] 50.0%
[2020-06-22.16:27:55] [Info] 60.0%
[2020-06-22.16:27:55] [Info] 70.0%
[2020-06-22.16:27:55] [Info] 80.0%
[2020-06-22.16:27:55] [Info] 90.0%
[2020-06-22.16:27:55] [Info] 100.0%
[2020-06-22.16:27:55] [Info] Tuning started
[2020-06-22.16:27:55] [Info] Results collection thread started
[2020-06-22.16:28:05] [Info] DP: 0 TP: 0 587.62 Mpt/s (10 iter/s)
[2020-06-22.16:28:15] [Info] DP: 0 TP: 0 1212.69 Mpt/s (20 iter/s)
[2020-06-22.16:28:25] [Info] DP: 0 TP: 0 1170.13 Mpt/s (20 iter/s)
[2020-06-22.16:28:28] [Info] Tuning complete
[2020-06-22.16:28:35] [Info] DP: 0 TP: 0 1187.71 Mpt/s (20 iter/s)
[2020-06-22.16:28:40] [Info] Verifying 2785 results
[2020-06-22.16:28:45] [Info] DP: 0 TP: 0 1325.58 Mpt/s (22 iter/s)
[2020-06-22.16:28:55] [Info] DP: 0 TP: 0 1322.54 Mpt/s (22 iter/s)
[2020-06-22.16:29:05] [Info] DP: 0 TP: 0 1315.67 Mpt/s (22 iter/s)
______ ______ __ ___ __ ___ ____ ____ ___
/ ____// ____/ / / / | / |/ // __ ) / __ \ / |
/ __/ / / / / / /| | / /|_/ // __ |/ / / // /| |
/ /___ / /___ / /___ / ___ | / / / // /_/ // /_/ // ___ |
/_____ / \____/ /_____//_/ |_|/_/ /_//_____//_____//_/ |_|
EC LAMBDA CLIENT
VERSION 1.1.1 ALPHA
[2020-06-22.16:26:33] [Info] Connecting to 127.0.0.1
[2020-06-22.16:26:34] [Info] Target public key:
[2020-06-22.16:26:34] [Info] X:F1367CC260779F7EA6C7E4B7258A4D31A4C41D6282C5200571CE10E748A4AADE
[2020-06-22.16:26:34] [Info] Y:0743F0CA057C7F39A9D9A20D4A93555B19F712920EEEF2F267466A2F3D08662E
[2020-06-22.16:26:34] [Info] Distinguisher: 24 bits
[2020-06-22.16:26:34] [Info] Sending results to server every 10 minutes
[2020-06-22.16:26:34] [Info] Initializing GeForce RTX 2080 SUPER
[2020-06-22.16:26:34] [Info] Compiling OpenCL kernels...
[2020-06-22.16:26:34] [Info] Initializing...
[2020-06-22.16:27:09] [Info] Generating 58,395,776 starting points (7184.1MB)
[2020-06-22.16:27:37] [Info] 10.0%
[2020-06-22.16:27:42] [Info] 20.0%
[2020-06-22.16:27:48] [Info] 30.0%
[2020-06-22.16:27:50] [Info] 40.0%
[2020-06-22.16:27:50] [Info] 50.0%
[2020-06-22.16:27:50] [Info] 60.0%
[2020-06-22.16:27:51] [Info] 70.0%
[2020-06-22.16:27:51] [Info] 80.0%
[2020-06-22.16:27:52] [Info] 90.0%
[2020-06-22.16:27:52] [Info] 100.0%
[2020-06-22.16:27:54] [Info] Refilling GPU cache (319.3MB)
[2020-06-22.16:27:54] [Info] 10.0%
[2020-06-22.16:27:54] [Info] 20.0%
[2020-06-22.16:27:55] [Info] 30.0%
[2020-06-22.16:27:55] [Info] 40.0%
[2020-06-22.16:27:55] [Info] 50.0%
[2020-06-22.16:27:55] [Info] 60.0%
[2020-06-22.16:27:55] [Info] 70.0%
[2020-06-22.16:27:55] [Info] 80.0%
[2020-06-22.16:27:55] [Info] 90.0%
[2020-06-22.16:27:55] [Info] 100.0%
[2020-06-22.16:27:55] [Info] Tuning started
[2020-06-22.16:27:55] [Info] Results collection thread started
[2020-06-22.16:28:05] [Info] DP: 0 TP: 0 587.62 Mpt/s (10 iter/s)
[2020-06-22.16:28:15] [Info] DP: 0 TP: 0 1212.69 Mpt/s (20 iter/s)
[2020-06-22.16:28:25] [Info] DP: 0 TP: 0 1170.13 Mpt/s (20 iter/s)
[2020-06-22.16:28:28] [Info] Tuning complete
[2020-06-22.16:28:35] [Info] DP: 0 TP: 0 1187.71 Mpt/s (20 iter/s)
[2020-06-22.16:28:40] [Info] Verifying 2785 results
[2020-06-22.16:28:45] [Info] DP: 0 TP: 0 1325.58 Mpt/s (22 iter/s)
[2020-06-22.16:28:55] [Info] DP: 0 TP: 0 1322.54 Mpt/s (22 iter/s)
[2020-06-22.16:29:05] [Info] DP: 0 TP: 0 1315.67 Mpt/s (22 iter/s)
It automatically finds the best grid size, so I do not know if it's useful to even display it.
Increasing --gpu-mem-usage increases performance. By default it's low to avoid timing out/crashing for people testing it on display GPUs.
Your soft support multypubkeys and multyadress in parallel ? DP calculated automatically ? As for me If DP not automatic soft waste many times, and waste money only, and not give result and not wary about count of used GPU, soft can waste fom 1 to inf GPU times !!!
https://github.com/brichard19/eclambda
Can anyone try my tool on a 2080ti? On a 2080S it gets around 1300MKeys/sec when using 24-bit DP.
Can anyone try my tool on a 2080ti? On a 2080S it gets around 1300MKeys/sec when using 24-bit DP.
I tried your tool (DP18) on a V100.
Code:
[2020-06-22.11:35:35] [Info] DP: 0 TP: 0 853.74 Mpt/s (64 iter/s)
[2020-06-22.11:35:37] [Info] Verifying 40336 results
[2020-06-22.11:35:45] [Info] DP: 0 TP: 0 992.50 Mpt/s (75 iter/s)
[2020-06-22.11:35:48] [Info] Verifying 40362 results
[2020-06-22.11:35:55] [Info] DP: 0 TP: 0 991.18 Mpt/s (75 iter/s)
[2020-06-22.11:35:37] [Info] Verifying 40336 results
[2020-06-22.11:35:45] [Info] DP: 0 TP: 0 992.50 Mpt/s (75 iter/s)
[2020-06-22.11:35:48] [Info] Verifying 40362 results
[2020-06-22.11:35:55] [Info] DP: 0 TP: 0 991.18 Mpt/s (75 iter/s)
Kangaroo on a server too, configured in the same way, however, it is not clear how many kangaroo are running in parallel with your program and what grid setting is used.
Code:
GPU: GPU #0 Tesla V100-PCIE-16GB (80x64 cores) Grid(160x128) (207.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^21.32 kangaroos [11.2s]
[2000.07 MK/s][GPU 2000.07 MK/s][Count 2^37.48][01:52][Server OK]
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^21.32 kangaroos [11.2s]
[2000.07 MK/s][GPU 2000.07 MK/s][Count 2^37.48][01:52][Server OK]
It says exactly how many kangaroos are running in parallel, 58,395,776 in this example:
Code:
eclambda --name testjob85 --gpu-mem-usage 0.9 --device 2
______ ______ __ ___ __ ___ ____ ____ ___
/ ____// ____/ / / / | / |/ // __ ) / __ \ / |
/ __/ / / / / / /| | / /|_/ // __ |/ / / // /| |
/ /___ / /___ / /___ / ___ | / / / // /_/ // /_/ // ___ |
/_____ / \____/ /_____//_/ |_|/_/ /_//_____//_____//_/ |_|
EC LAMBDA CLIENT
VERSION 1.1.1 ALPHA
[2020-06-22.16:26:33] [Info] Connecting to 127.0.0.1
[2020-06-22.16:26:34] [Info] Target public key:
[2020-06-22.16:26:34] [Info] X:F1367CC260779F7EA6C7E4B7258A4D31A4C41D6282C5200571CE10E748A4AADE
[2020-06-22.16:26:34] [Info] Y:0743F0CA057C7F39A9D9A20D4A93555B19F712920EEEF2F267466A2F3D08662E
[2020-06-22.16:26:34] [Info] Distinguisher: 24 bits
[2020-06-22.16:26:34] [Info] Sending results to server every 10 minutes
[2020-06-22.16:26:34] [Info] Initializing GeForce RTX 2080 SUPER
[2020-06-22.16:26:34] [Info] Compiling OpenCL kernels...
[2020-06-22.16:26:34] [Info] Initializing...
[2020-06-22.16:27:09] [Info] Generating 58,395,776 starting points (7184.1MB)
[2020-06-22.16:27:37] [Info] 10.0%
[2020-06-22.16:27:42] [Info] 20.0%
[2020-06-22.16:27:48] [Info] 30.0%
[2020-06-22.16:27:50] [Info] 40.0%
[2020-06-22.16:27:50] [Info] 50.0%
[2020-06-22.16:27:50] [Info] 60.0%
[2020-06-22.16:27:51] [Info] 70.0%
[2020-06-22.16:27:51] [Info] 80.0%
[2020-06-22.16:27:52] [Info] 90.0%
[2020-06-22.16:27:52] [Info] 100.0%
[2020-06-22.16:27:54] [Info] Refilling GPU cache (319.3MB)
[2020-06-22.16:27:54] [Info] 10.0%
[2020-06-22.16:27:54] [Info] 20.0%
[2020-06-22.16:27:55] [Info] 30.0%
[2020-06-22.16:27:55] [Info] 40.0%
[2020-06-22.16:27:55] [Info] 50.0%
[2020-06-22.16:27:55] [Info] 60.0%
[2020-06-22.16:27:55] [Info] 70.0%
[2020-06-22.16:27:55] [Info] 80.0%
[2020-06-22.16:27:55] [Info] 90.0%
[2020-06-22.16:27:55] [Info] 100.0%
[2020-06-22.16:27:55] [Info] Tuning started
[2020-06-22.16:27:55] [Info] Results collection thread started
[2020-06-22.16:28:05] [Info] DP: 0 TP: 0 587.62 Mpt/s (10 iter/s)
[2020-06-22.16:28:15] [Info] DP: 0 TP: 0 1212.69 Mpt/s (20 iter/s)
[2020-06-22.16:28:25] [Info] DP: 0 TP: 0 1170.13 Mpt/s (20 iter/s)
[2020-06-22.16:28:28] [Info] Tuning complete
[2020-06-22.16:28:35] [Info] DP: 0 TP: 0 1187.71 Mpt/s (20 iter/s)
[2020-06-22.16:28:40] [Info] Verifying 2785 results
[2020-06-22.16:28:45] [Info] DP: 0 TP: 0 1325.58 Mpt/s (22 iter/s)
[2020-06-22.16:28:55] [Info] DP: 0 TP: 0 1322.54 Mpt/s (22 iter/s)
[2020-06-22.16:29:05] [Info] DP: 0 TP: 0 1315.67 Mpt/s (22 iter/s)
______ ______ __ ___ __ ___ ____ ____ ___
/ ____// ____/ / / / | / |/ // __ ) / __ \ / |
/ __/ / / / / / /| | / /|_/ // __ |/ / / // /| |
/ /___ / /___ / /___ / ___ | / / / // /_/ // /_/ // ___ |
/_____ / \____/ /_____//_/ |_|/_/ /_//_____//_____//_/ |_|
EC LAMBDA CLIENT
VERSION 1.1.1 ALPHA
[2020-06-22.16:26:33] [Info] Connecting to 127.0.0.1
[2020-06-22.16:26:34] [Info] Target public key:
[2020-06-22.16:26:34] [Info] X:F1367CC260779F7EA6C7E4B7258A4D31A4C41D6282C5200571CE10E748A4AADE
[2020-06-22.16:26:34] [Info] Y:0743F0CA057C7F39A9D9A20D4A93555B19F712920EEEF2F267466A2F3D08662E
[2020-06-22.16:26:34] [Info] Distinguisher: 24 bits
[2020-06-22.16:26:34] [Info] Sending results to server every 10 minutes
[2020-06-22.16:26:34] [Info] Initializing GeForce RTX 2080 SUPER
[2020-06-22.16:26:34] [Info] Compiling OpenCL kernels...
[2020-06-22.16:26:34] [Info] Initializing...
[2020-06-22.16:27:09] [Info] Generating 58,395,776 starting points (7184.1MB)
[2020-06-22.16:27:37] [Info] 10.0%
[2020-06-22.16:27:42] [Info] 20.0%
[2020-06-22.16:27:48] [Info] 30.0%
[2020-06-22.16:27:50] [Info] 40.0%
[2020-06-22.16:27:50] [Info] 50.0%
[2020-06-22.16:27:50] [Info] 60.0%
[2020-06-22.16:27:51] [Info] 70.0%
[2020-06-22.16:27:51] [Info] 80.0%
[2020-06-22.16:27:52] [Info] 90.0%
[2020-06-22.16:27:52] [Info] 100.0%
[2020-06-22.16:27:54] [Info] Refilling GPU cache (319.3MB)
[2020-06-22.16:27:54] [Info] 10.0%
[2020-06-22.16:27:54] [Info] 20.0%
[2020-06-22.16:27:55] [Info] 30.0%
[2020-06-22.16:27:55] [Info] 40.0%
[2020-06-22.16:27:55] [Info] 50.0%
[2020-06-22.16:27:55] [Info] 60.0%
[2020-06-22.16:27:55] [Info] 70.0%
[2020-06-22.16:27:55] [Info] 80.0%
[2020-06-22.16:27:55] [Info] 90.0%
[2020-06-22.16:27:55] [Info] 100.0%
[2020-06-22.16:27:55] [Info] Tuning started
[2020-06-22.16:27:55] [Info] Results collection thread started
[2020-06-22.16:28:05] [Info] DP: 0 TP: 0 587.62 Mpt/s (10 iter/s)
[2020-06-22.16:28:15] [Info] DP: 0 TP: 0 1212.69 Mpt/s (20 iter/s)
[2020-06-22.16:28:25] [Info] DP: 0 TP: 0 1170.13 Mpt/s (20 iter/s)
[2020-06-22.16:28:28] [Info] Tuning complete
[2020-06-22.16:28:35] [Info] DP: 0 TP: 0 1187.71 Mpt/s (20 iter/s)
[2020-06-22.16:28:40] [Info] Verifying 2785 results
[2020-06-22.16:28:45] [Info] DP: 0 TP: 0 1325.58 Mpt/s (22 iter/s)
[2020-06-22.16:28:55] [Info] DP: 0 TP: 0 1322.54 Mpt/s (22 iter/s)
[2020-06-22.16:29:05] [Info] DP: 0 TP: 0 1315.67 Mpt/s (22 iter/s)
It automatically finds the best grid size, so I do not know if it's useful to even display it.
Increasing --gpu-mem-usage increases performance. By default it's low to avoid timing out/crashing for people testing it on display GPUs.
-snip-
I don't know so I'm not disagreeing with you but why would you need to cut any tame or wild out?
Same range, only thing changing would be what x coord to look for and compare for solution, right?
here is my reconstructor https://drive.google.com/file/d/1zHwoVjIvYhpgcTy_4sWin_A-3GMiTs5BI don't know so I'm not disagreeing with you but why would you need to cut any tame or wild out?
Same range, only thing changing would be what x coord to look for and compare for solution, right?
when you will first time reconstruct workfile use -checkdp 1 in bat file.
After few persent(or fraction of persent) of job if there will be ok and you don`t get any eror message then close reconstructor> set -checkdp 0> and launch again.
-checkdp 1 need only to see if wild DPs tamed in correct way.
param newpubkey use without prefix 04
If you will see error with -checkdp 1 than previousprivkey set invalid and recocosntructed wild DP has x-coordinate not the same as in source.
Source file not changed during reconstruction.. All DPs going to new work file.
After end of reconstruction you will see somesing like this:
Code:
100.00%
DP count :240568
HT max :8[@ 01D30E]
HT min :0[@ 000001]
Tame count :120410
Wild count :120158
NumberOfWalk:0000000000000000
------------------------
TAME [120410]
TAMED [120158]
SKIPED[0]
TOTAL TAME[240568]
Edit: if you not tamed your wild DPs they are useless to search new pubkeys, just DP count :240568
HT max :8[@ 01D30E]
HT min :0[@ 000001]
Tame count :120410
Wild count :120158
NumberOfWalk:0000000000000000
------------------------
TAME [120410]
TAMED [120158]
SKIPED[0]
TOTAL TAME[240568]
only memory is used, but there is no sense from them.
It is possible that they will lead to incorrect collisions if not tamed.
@Jean Luc
Don't tell me about times or it's not worth it etc. (please):
If I solved a key at the 100 bit range and I want to reuse the dp file generated from that search, how do I reuse it to search for another pubkey in the exact same range and using the exact same dp?
Seems like I'd have to clear out pubkey in header, that all? How to go about it?
You need tamed wild DPs or cut wild DPs from workfile.Don't tell me about times or it's not worth it etc. (please):
If I solved a key at the 100 bit range and I want to reuse the dp file generated from that search, how do I reuse it to search for another pubkey in the exact same range and using the exact same dp?
Seems like I'd have to clear out pubkey in header, that all? How to go about it?
Same range, only thing changing would be what x coord to look for and compare for solution, right?
@Jean Luc
Don't tell me about times or it's not worth it etc. (please):
If I solved a key at the 100 bit range and I want to reuse the dp file generated from that search, how do I reuse it to search for another pubkey in the exact same range and using the exact same dp?
Seems like I'd have to clear out pubkey in header, that all? How to go about it?
You need tamed wild DPs or cut wild DPs from workfile.Don't tell me about times or it's not worth it etc. (please):
If I solved a key at the 100 bit range and I want to reuse the dp file generated from that search, how do I reuse it to search for another pubkey in the exact same range and using the exact same dp?
Seems like I'd have to clear out pubkey in header, that all? How to go about it?
@Jean Luc
Don't tell me about times or it's not worth it etc. (please):
If I solved a key at the 100 bit range and I want to reuse the dp file generated from that search, how do I reuse it to search for another pubkey in the exact same range and using the exact same dp?
Seems like I'd have to clear out pubkey in header, that all? How to go about it?
Don't tell me about times or it's not worth it etc. (please):
If I solved a key at the 100 bit range and I want to reuse the dp file generated from that search, how do I reuse it to search for another pubkey in the exact same range and using the exact same dp?
Seems like I'd have to clear out pubkey in header, that all? How to go about it?
if i am not wrong,
you win 115bit puzzle in 13 days, and you count 120 puzzle is more hard as 32 time
its mean 13 x 32 = 416 days you need to win or ?
you win 115bit puzzle in 13 days, and you count 120 puzzle is more hard as 32 time
its mean 13 x 32 = 416 days you need to win or ?
Pollard Kangaroo time grows with square root of the problem.
13 x sqrt(32) = 74 days
The expected time is lower ~45 days.
Quote
Expected time: 2 months on 256 Tesla V100
if i am not wrong,
you win 115bit puzzle in 13 days, and you count 120 puzzle is more hard as 32 time
its mean 13 x 32 = 416 days you need to win or ?
you win 115bit puzzle in 13 days, and you count 120 puzzle is more hard as 32 time
its mean 13 x 32 = 416 days you need to win or ?
Pollard Kangaroo time grows with square root of the problem.
13 x sqrt(32) = 74 days
The expected time is lower ~45 days.
You are using a too small DP, too much DPs enter in the HashTable and slow down the search.
The expected RAM to reach 50% probability is 60GB.
And last but not least, you CPU work also and prevent the other threads to work.
Try DP17 or 18 and use -t 0 (no CPU) option.
Kangaroo.exe -d 17 -t 0 -gpu -gpuId 0,1,2,3 -g 136,128,136,128,136,128,136,128 in.txt
if i am not wrong, The expected RAM to reach 50% probability is 60GB.
And last but not least, you CPU work also and prevent the other threads to work.
Try DP17 or 18 and use -t 0 (no CPU) option.
Kangaroo.exe -d 17 -t 0 -gpu -gpuId 0,1,2,3 -g 136,128,136,128,136,128,136,128 in.txt
you win 115bit puzzle in 13 days, and you count 120 puzzle is more hard as 32 time
its mean 13 x 32 = 416 days you need to win or ?
You are using a too small DP, too much DPs enter in the HashTable and slow down the search.
The expected RAM to reach 50% probability is 60GB.
And last but not least, you CPU work also and prevent the other threads to work.
Try DP17 or 18 and use -t 0 (no CPU) option.
Kangaroo.exe -d 17 -t 0 -gpu -gpuId 0,1,2,3 -g 136,128,136,128,136,128,136,128 in.txt
The expected RAM to reach 50% probability is 60GB.
And last but not least, you CPU work also and prevent the other threads to work.
Try DP17 or 18 and use -t 0 (no CPU) option.
Kangaroo.exe -d 17 -t 0 -gpu -gpuId 0,1,2,3 -g 136,128,136,128,136,128,136,128 in.txt
Jean_Luc, why power downgrade from 8000 mkey to 1600 Mkey's ?
I run 89 Byte range on 4x2080 Ti. I have 30 GB free memory, and 34 GB used memory by Kangaroo.
start work :
.....
midle of work:
Jean_Luc, fix this please
? How to use this ? Avg move from 3h to 1.d !!!!
I run 89 Byte range on 4x2080 Ti. I have 30 GB free memory, and 34 GB used memory by Kangaroo.
start work :
Code:
Start:10000000000
Stop :1FFFFFFFFFFFFFFFFFFFFFF
Keys :22
Number of CPU thread: 5
Range width: 2^89
Jump Avg distance: 2^44.00
Number of kangaroos: 2^24.09
Suggested DP: 17
Expected operations: 2^45.57
Expected RAM: 60622.8MB
DP size: 15 [0xFFFE000000000000]
SolveKeyCPU Thread 0: 1024 kangaroos
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 2: 1024 kangaroos
SolveKeyCPU Thread 3: 1024 kangaroos
SolveKeyCPU Thread 4: 1024 kangaroos
GPU: GPU #3 GeForce RTX 2080 Ti (68x64 cores) Grid(136x256) (347.0 MB used)
SolveKeyGPU Thread GPU#3: creating kangaroos...
GPU: GPU #1 GeForce RTX 2080 Ti (68x64 cores) Grid(136x256) (347.0 MB used)
SolveKeyGPU Thread GPU#1: creating kangaroos...
GPU: GPU #0 GeForce RTX 2080 Ti (68x64 cores) Grid(136x256) (347.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
GPU: GPU #2 GeForce RTX 2080 Ti (68x64 cores) Grid(136x256) (347.0 MB used)
SolveKeyGPU Thread GPU#2: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^22.09 kangaroos [26.4s]
SolveKeyGPU Thread GPU#3: 2^22.09 kangaroos [26.5s]
SolveKeyGPU Thread GPU#2: 2^22.09 kangaroos [29.4s]
SolveKeyGPU Thread GPU#1: 2^22.09 kangaroos [29.9s]
[7319.21 MK/s][GPU 4249.73 MK/s][Count 2^34.14][Dead 0][02s (Avg 01:58:33)][19.6
[9481.52 MK/s][GPU 6403.06 MK/s][Count 2^34.79][Dead 0][04s (Avg 01:31:31)][29.6
[8483.26 MK/s][GPU 6422.12 MK/s][Count 2^35.24][Dead 0][07s (Avg 01:42:17)][39.7
[7186.98 MK/s][GPU 5890.89 MK/s][Count 2^35.58][Dead 0][09s (Avg 02:00:44)][49.7
[6349.58 MK/s][GPU 5462.11 MK/s][Count 2^35.85][Dead 0][12s (Avg 02:16:39)][59.6
[5867.72 MK/s][GPU 5193.33 MK/s][Count 2^36.08][Dead 0][14s (Avg 02:27:52)][69.6
[5574.25 MK/s][GPU 5024.18 MK/s][Count 2^36.28][Dead 0][17s (Avg 02:35:40)][79.7
[5381.29 MK/s][GPU 4913.37 MK/s][Count 2^36.46][Dead 0][19s (Avg 02:41:15)][89.8
/124.6MB] ^CЗaвepшить выпoлнeниe пaкeтнoгo фaйлa [Y(дa)/N(нeт)]?
.....
midle of work:
Code:
[366.98 MK/s][GPU 366.71 MK/s][Count 2^44.10][Dead 0][02:00:59 (Avg 1.6d)][17582
[363.40 MK/s][GPU 363.14 MK/s][Count 2^44.10][Dead 0][02:01:01 (Avg 1.7d)][17583
[368.80 MK/s][GPU 368.53 MK/s][Count 2^44.10][Dead 0][02:01:18 (Avg 1.6d)][17588
[373.03 MK/s][GPU 372.76 MK/s][Count 2^44.10][Dead 0][02:01:21 (Avg 1.6d)][17589
[369.99 MK/s][GPU 369.73 MK/s][Count 2^44.10][Dead 0][02:01:23 (Avg 1.6d)][17590
[369.60 MK/s][GPU 369.34 MK/s][Count 2^44.10][Dead 0][02:01:26 (Avg 1.6d)][17591
.0/21995.3MB]
Jean_Luc, fix this please
? How to use this ? Avg move from 3h to 1.d !!!! \Tell me is there any option to use multiply GPU on BitCrack or Vanity because i have 1k Gpu idle
AFAIK on BitCrack you may use only one GPU per process, which means that yuo must share your work between different processes.
I think bitcrack get some GPU power from all clients !!! 50% I think. Bitcrack online version is not Yours online, bat someone else
\Tell me is there any option to use multiply GPU on BitCrack or Vanity because i have 1k Gpu idle
AFAIK on BitCrack you may use only one GPU per process, which means that yuo must share your work between different processes.
Jump to: