In the end Jean Luc took the chance from all with the knowledge of creating a working Pollard Kangaroo for GPU and gave it to those with the power but no knowledge.
I am sure #115, #120 and #125 will go to zielar and no pool can compete. gg.
Topic: Pollard's kangaroo ECDLP solver - page 110. (Read 58665 times)
As said in the README the server is simple and doesn't have an authentication mechanism.
It is quite easy for a hacker to make it crash or make it generate wrong collision to make the server unusable.
So, do not export this server to the world or hide the ip and port and give server address to trusted person only.
It is quite easy for a hacker to make it crash or make it generate wrong collision to make the server unusable.
So, do not export this server to the world or hide the ip and port and give server address to trusted person only.
-snip-
If you need it I can put together a C program, I think at least 100k key/s are possible, then 2^30 points in less than 3 hours; what speed do you think you need? How much DPs you want to check per hour?
At picture 1 2080ti produce 2200DPs every 2seconds. the same 2^30.5(Nop) / 20^20(Dpsize)=2^10.5 DP/s = 1176If you need it I can put together a C program, I think at least 100k key/s are possible, then 2^30 points in less than 3 hours; what speed do you think you need? How much DPs you want to check per hour?
If there will be for example 100 GPU 2080ti it is 110K DP/s need to be verified.
To prevent crash kangaroo server we need only check hash mask. But it is not enouch to prevent addiding job to bad actor.
Everyone can easy make forge DP where mask correct(0<=mask<1<<18), but distance and x-coordinate is fake.
Without verification this DP, actor will get +1DP to his account.
The same like in mining where each share from miner verified we need verify each DP.
-snip-
-snip-
Code:
error : Designtime build failed for project 'C:\Users\danh\Desktop\kg\Kangaroo-master\VC_CUDA102\Kangaroo.vcxproj' configuration 'Release|x64'. IntelliSense might be unavailable.
Set environment variable TRACEDESIGNTIME = true and restart Visual Studio to investigate.
Set environment variable TRACEDESIGNTIME = true and restart Visual Studio to investigate.
-snip-
Hi Dan.
I am not using Visual Studio.
I googled the problem and found some solutions that say you should repair the project (I think there is a menu option) or upgrade your visual studio.
-snip-
Checking the DPs only for validity does not mean performing the entire work again. Kangaroos are jumping from one point to another based on visited x-coordinate, and as soon as kangaroo lands the x-coordinate with the determined pattern (i.e. coordinate with 25 leading zeros -----snip-
Checking the DPs only for validity does not mean performing the entire work again. Kangaroos are jumping from one point to another based on visited x-coordinate, and as soon as kangaroo lands the x-coordinate with the determined pattern (i.e. coordinate with 25 leading zeros -----snip-
As far as I understand it is important that the DP is from a real kangaroo walk.
The difference:
As soon as a kangaroo hits a point (a point that is not qualified to be a DP by bitmask) that has been visited by a kangaroo of the other type, their walks are synchronized and the next DP they find will definately result in a collision and PK is found.
This is not the case with randomly selected points in the range that fullfill the DP bitmask criteria.
It is possible that there will be a collision with these kind of "not real walk" points though.
Hello,
Thank you for allowing public testing of your code.
I am using CUDA 10.2 and VS 2017 (15.9), Windows Server 2019 on Google Console with a GPU Tesla V100.
I am trying to compile in VS but I can't seem to get rid of this error:
Any suggestions appreciated.
Thanks for your time.
Dan
Thank you for allowing public testing of your code.
I am using CUDA 10.2 and VS 2017 (15.9), Windows Server 2019 on Google Console with a GPU Tesla V100.
I am trying to compile in VS but I can't seem to get rid of this error:
Code:
error : Designtime build failed for project 'C:\Users\danh\Desktop\kg\Kangaroo-master\VC_CUDA102\Kangaroo.vcxproj' configuration 'Release|x64'. IntelliSense might be unavailable.
Set environment variable TRACEDESIGNTIME = true and restart Visual Studio to investigate.
Set environment variable TRACEDESIGNTIME = true and restart Visual Studio to investigate.
Any suggestions appreciated.
Thanks for your time.
Dan
-snip-
You would need to check that the DP is actually valid though. That involves performing the entire walk. If you did this for every DP you would be re-doing the entire computation.
One way to do this would to include a checksum with the DP whete the checksum is the count of each jump point that makes up the DP. To verify it the server multiplies and adds the counts and the jump points together. This would involve more work for the client since it would need to keep count for every walk.
You would need to check that the DP is actually valid though. That involves performing the entire walk. If you did this for every DP you would be re-doing the entire computation.
One way to do this would to include a checksum with the DP whete the checksum is the count of each jump point that makes up the DP. To verify it the server multiplies and adds the counts and the jump points together. This would involve more work for the client since it would need to keep count for every walk.
Checking the DPs only for validity does not mean performing the entire work again. Kangaroos are jumping from one point to another based on visited x-coordinate, and as soon as kangaroo lands the x-coordinate with the determined pattern (i.e. coordinate with 25 leading zeros from total 256 bits for DP 25) this coordinate is saved to hashtable together with the distance. So we have saved distance and x-coordinate (only 2nd half of it with length 128 bit).
To check one tame point from hashtable we just need perform one elliptic curve multiplication - converting distance (i.e. private key) to public key and compare last 128 bits of x-coordinate with saved in hashtable. For wild points we should perform one elliptic curve multiplication and addition/subtraction - compute public key from the distance and add/subtract the received point with the target public key, and compare the resulted x-coordinate with hashtable. {ok, actually it is not one addition and multiplication it consists from 32 additions, but it depends on the used algorithm and pre-computed points}
Also no need to save the whole path of the kangaroos. Only the final distinguished point (DP) with the total distance is important.
But we should not make the whole job again to check the DP. Client should perform approximately 2^25 jumps (operations) in order to find one DP. On server side we need to perform just one operation.
Agree with arulbero
I am working on pool to solve keys together.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
Are you sure?
key #110 was solved with 2^30.55 DP in 2 days
A normal cpu can compute consecutive keys very fast, my cpu computes almost 30 Mkeys/s, let's say 2^24 keys/s; it would take less than 2 minutes to check 2^30 points
computing random points is slower, but even if it takes x100, we are talking about 3 hours for the entire hash table.
With a simple python script I can get 2^12 keys/s, but it is not tailored for the public keys with private keys so short (under 128 bit) it could reach at least 2^13 keys/s with keys so short.
If you need it I can put together a C program, I think at least 100k key/s are possible, then 2^30 points in less than 3 hours; what speed do you think you need? How much DPs you want to check per hour?
I am working on pool to solve keys together.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
Are you sure?
key #110 was solved with 2^30.55 DP in 2 days
A normal cpu can compute consecutive keys very fast, my cpu computes almost 30 Mkeys/s, let's say 2^24 keys/s; it would take less than 2 minutes to check 2^30 points
computing random points is slower, but even if it takes x100, we are talking about 3 hours for the entire hash table.
With a simple python script I can get 2^12 keys/s, but it is not tailored for the public keys with private keys so short (under 128 bit) it could reach at least 2^13 keys/s with keys so short.
If you need it I can put together a C program, I think at least 100k key/s are possible, then 2^30 points in less than 3 hours; what speed do you think you need? How much DPs you want to check per hour?
You would need to check that the DP is actually valid though. That involves performing the entire walk. If you did this for every DP you would be re-doing the entire computation.
One way to do this would to include a checksum with the DP whete the checksum is the count of each jump point that makes up the DP. To verify it the server multiplies and adds the counts and the jump points together. This would involve more work for the client since it would need to keep count for every walk.
Is it really that important a DP was generated by a walk? Why aren't any points that satisfy the DP criteria (bitmask) valid and usefull?
Edit: I understand now that each DP must be generated by a real Pollard Kangaroo walk for the synchronizing effect of the walk.
Maybe different approach for parallelizing the work:
Q = our target pubkey in 115 bit range
If you have 16 GPUs prepare a new set S of pubkeys:
for n = 0 to 16
S[n] = (Q-n)/16
Now you have a set S with 16 new derived pubkeys where only one is in the range targetBitrange-4 (for 115 it is now in 111 bit range).
So it is true that 15 GPUs will work on pubkeys that are in a different range and this work is useless. But one GPU is working in the correct 111 bit range.
Would this be a benefit?
Edit:
BitCrack, I like your solution for verifying the work but maybe it can be faked too when there is a bad actor that wants to mess with the pool data?
I am working on pool to solve keys together.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
Buddy, you realy thant crack 1 Btc pusle ? I have many BTC REAL PUBKEYS with 40 BTC AND MORE fore cooperate crack. Do you agree crack 40 BTC and more and share profit ? 40 BTC - this is a forgotten for 10 years and wallet. If not, your 1 BTC puzle not interested for for cooperation crack. If you ready crack more then 1 BTC, we well can ccoperate and get some profit, and share profit with Jean_Luc. If you not Bro, I will do it yourself. My country is a sheet country and I Thant go away from sheet.
?Hello. I was talk with the Etar, and not talk bout forgotten wallets, but only forgotten addressee. Ditherent is understand for you ? If you realy can crck forgotten adress You Are welcome to pm me.
Now I was accept. Your's messages are welcomed !!!
I am working on pool to solve keys together.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
Are you sure?
key #110 was solved with 2^30.55 DP in 2 days
A normal cpu can compute consecutive keys very fast, my cpu computes almost 30 Mkeys/s, let's say 2^24 keys/s; it would take less than 2 minutes to check 2^30 points
computing random points is slower, but even if it takes x100, we are talking about 3 hours for the entire hash table.
With a simple python script I can get 2^12 keys/s, but it is not tailored for the public keys with private keys so short (under 128 bit) it could reach at least 2^13 keys/s with keys so short.
If you need it I can put together a C program, I think at least 100k key/s are possible, then 2^30 points in less than 3 hours; what speed do you think you need? How much DPs you want to check per hour?
You would need to check that the DP is actually valid though. That involves performing the entire walk. If you did this for every DP you would be re-doing the entire computation.
One way to do this would to include a checksum with the DP whete the checksum is the count of each jump point that makes up the DP. To verify it the server multiplies and adds the counts and the jump points together. This would involve more work for the client since it would need to keep count for every walk.
I am working on pool to solve keys together.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
Are you sure?
key #110 was solved with 2^30.55 DP in 2 days
A normal cpu can compute consecutive keys very fast, my cpu computes almost 30 Mkeys/s, let's say 2^24 keys/s; it would take less than 2 minutes to check 2^30 points
computing random points is slower, but even if it takes x100, we are talking about 3 hours for the entire hash table.
With a simple python script I can get 2^12 keys/s, but it is not tailored for the public keys with private keys so short (under 128 bit) it could reach at least 2^13 keys/s with keys so short.
If you need it I can put together a C program, I think at least 100k key/s are possible, then 2^30 points in less than 3 hours; what speed do you think you need? How much DPs you want to check per hour?
You would need to check that the DP is actually valid though. That involves performing the entire walk. If you did this for every DP you would be re-doing the entire computation.
One way to do this would to include a checksum with the DP whete the checksum is the count of each jump point that makes up the DP. To verify it the server multiplies and adds the counts and the jump points together. This would involve more work for the client since it would need to keep count for every walk.
I am working on pool to solve keys together.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
Are you sure?
key #110 was solved with 2^30.55 DP in 2 days
A normal cpu can compute consecutive keys very fast, my cpu computes almost 30 Mkeys/s, let's say 2^24 keys/s; it would take less than 2 minutes to check 2^30 points
computing random points is slower, but even if it takes x100, we are talking about 3 hours for the entire hash table.
With a simple python script I can get 2^12 keys/s, but it is not tailored for the public keys with private keys so short (under 128 bit) it could reach at least 2^13 keys/s with keys so short.
If you need it I can put together a C program, I think at least 100k key/s are possible, then 2^30 points in less than 3 hours; what speed do you think you need? How much DPs you want to check per hour?
I am working on pool to solve keys together.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
Buddy, you realy thant crack 1 Btc pusle ? I have many BTC REAL PUBKEYS with 40 BTC AND MORE fore cooperate crack. Do you agree crack 40 BTC and more and share profit ? 40 BTC - this is a forgotten for 10 years and wallet. If not, your 1 BTC puzle not interested for for cooperation crack. If you ready crack more then 1 BTC, we well can ccoperate and get some profit, and share profit with Jean_Luc. If you not Bro, I will do it yourself. My country is a sheet country and I Thant go away from sheet.
?Hello. I was talk with the Etar, and not talk bout forgotten wallets, but only forgotten addressee. Ditherent is understand for you ? If you realy can crck forgotten adress You Are welcome to pm me.
I am working on pool to solve keys together.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
Buddy, you realy thant crack 1 Btc pusle ? I have many BTC REAL PUBKEYS with 40 BTC AND MORE fore cooperate crack. Do you agree crack 40 BTC and more and share profit ? 40 BTC - this is a forgotten for 10 years and wallet. If not, your 1 BTC puzle not interested for for cooperation crack. If you ready crack more then 1 BTC, we well can ccoperate and get some profit, and share profit with Jean_Luc. If you not Bro, I will do it yourself. My country is a sheet country and I Thant go away from sheet.
?Hello. I was talk with the Etar, and not talk bout forgotten wallets, but only forgotten addressee. Ditherent is understand for you ? If you realy can crck forgotten adress You Are welcome to pm me.
I am working on pool to solve keys together.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
Buddy, you realy thant crack 1 Btc pusle ? I have many BTC REAL PUBKEYS with 40 BTC AND MORE fore cooperate crack. Do you agree crack 40 BTC and more and share profit ? 40 BTC - this is a forgotten for 10 years and wallet. If not, your 1 BTC puzle not interested for for cooperation crack. If you ready crack more then 1 BTC, we well can ccoperate and get some profit, and share profit with Jean_Luc. If you not Bro, I will do it yourself. My country is a sheet country and I Thant go away from sheet.
?I am working on pool to solve keys together.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
So is it a matter of let's say my equipment sending bad data, or me manipulating data? If it's because people may manipulate the DP data, only allow people you trust. ?
I am working on pool to solve keys together.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
Buddy, you realy thant crack 1 Btc pusle ? I have many BTC REAL PUBKEYS with 40 BTC AND MORE fore cooperate crack. Do you agree crack 40 BTC and more and share profit ? 40 BTC - this is a forgotten for 10 years and wallet. If not, your 1 BTC puzle not interested for for cooperation crack. If you ready crack more then 1 BTC, we well can ccoperate and get some profit, and share profit with Jean_Luc. If you not Bro, I will do it yourself. My country is a sheet country and I Thant go away from sheet.
?
I am working on pool to solve keys together.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
It is shema how it should be:
HelpServer and HelpClient needed to map each DP to a specific account.
As you can see in the next picture each sent DP is added to a specific account.
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
So the reason why the GPUs find solution faster, is by the sheer number of Kangaroos they bring to the hunt? Example, I can find solution 50 times faster with GPU versus CPU, but GPU has more than 50 times the amount of Kangaroos. Something like that?
Exactly.
For example look at the number of the kangaroos and at the speed for my cpu:
.\Kangaroo -t 4 .\in.txt
Start:49DCCFD96DC5DF56487436F5A1B18C4F5D34F65DDB48CB5E0000000000000000
Stop :49DCCFD96DC5DF56487436F5A1B18C4F5D34F65DDB48CB5EFFFFFFFFFFFFFFFF
Keys :2
Number of CPU thread: 4
Range width: 2^64
Number of random walk: 2^12.00 (Max DP=18)
DP size: 18 [0xFFFFC00000000000]
SolveKeyCPU Thread 0: 1024 kangaroos
SolveKeyCPU Thread 2: 1024 kangaroos
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 3: 1024 kangaroos
[17.67 MKey/s][GPU 0.00 MKey/s][Count 2^26.19][Dead 0][06s][1.1MB]
and for my gpu:
.\Kangaroo -gpu -t 4 .\in.txt
Start:49DCCFD96DC5DF56487436F5A1B18C4F5D34F65DDB48CB5E0000000000000000
Stop :49DCCFD96DC5DF56487436F5A1B18C4F5D34F65DDB48CB5EFFFFFFFFFFFFFFFF
Keys :2
Number of CPU thread: 4
Range width: 2^64
Number of random walk: 2^19.01 (Max DP=10)
DP size: 10 [0xFFC0000000000000]
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 3: 1024 kangaroos
SolveKeyCPU Thread 2: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos
GPU: GPU #0 Quadro M2200 (8x128 cores) Grid(16x256) (57.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^19.00 kangaroos in 3848.2ms
[68.93 MKey/s][GPU 37.47 MKey/s][Count 2^29.12][Dead 0][14s][48.3MB]
CPU: 1024 kangaroos times 4, speed: 17.67 MKey/s
GPU: 2^19 kangaroos, speed: 69 MKey/s
kangaroo speed on cpu: 17.67 MKey/s / 4096 = 4314 key/s
kangaroo speed on gpu: 68.93 MKey/s / 2^19 = 131 key/s
In my case each kangaroo on cpu moves 33 faster than a kangaroo on the gpu.
But my cpu has 4096=2^12 kangaroos against 2^19 kangaroos on the gpu (128 less)
Ahhhh...makes sense. Thank you for taking the time to respond. I appreciate it.
Jump to: