Author

Topic: Pollard's kangaroo ECDLP solver - page 111. (Read 59389 times)

full member
Activity: 1162
Merit: 237
Shooters Shoot...
June 02, 2020, 08:30:10 PM
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.

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?
What part of code needs tweaked to work with smaller priv keys?
newbie
Activity: 17
Merit: 25
June 02, 2020, 07:14:16 PM
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.

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?

member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
June 02, 2020, 06:32:51 PM
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.



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.

Huh?

Send me what info you have on your forgotten wallets.

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.
Says you do not accept PMs from "Newbies"

Now I was accept. Your's messages are welcomed !!!
full member
Activity: 1162
Merit: 237
Shooters Shoot...
June 02, 2020, 06:17:15 PM
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.

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.
Could you split the work; have separate server/another CPU verifying the DPs, once it checks, it dumps the files; if invalid DP is found, it notifies main server?
jr. member
Activity: 30
Merit: 122
June 02, 2020, 06:13:27 PM
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.

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.
legendary
Activity: 1932
Merit: 2077
June 02, 2020, 04:54:05 PM
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.

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?
full member
Activity: 1162
Merit: 237
Shooters Shoot...
June 02, 2020, 04:33:30 PM
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.



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.

Huh?

Send me what info you have on your forgotten wallets.

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.
Says you do not accept PMs from "Newbies"
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
June 02, 2020, 04:02:49 PM
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.



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.

Huh?

Send me what info you have on your forgotten wallets.

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.
full member
Activity: 1162
Merit: 237
Shooters Shoot...
June 02, 2020, 03:59:49 PM
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.



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.

Huh?

Send me what info you have on your forgotten wallets.
full member
Activity: 1162
Merit: 237
Shooters Shoot...
June 02, 2020, 03:58:10 PM
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.


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. ?
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
June 02, 2020, 03:49:59 PM
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.



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.



Huh?
sr. member
Activity: 642
Merit: 316
June 02, 2020, 03:34:46 PM
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.


full member
Activity: 1162
Merit: 237
Shooters Shoot...
June 02, 2020, 03:18:00 PM
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.
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
June 02, 2020, 02:59:05 PM
And everybody, do nor forget share your profit with Jean_Luc !!! And that's it, don't forget to share your profits with Jean_Luc !!! All normal people share your profits, every single person, don't forget where and where they are, don't forget their fucking and shitty country, and don't forget people like Jean_Luc who help you get out of your shitty country and poverty ...
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
June 02, 2020, 02:39:23 PM
-snip-
Lets Ford will be winner  Grin But all who have no 20 GPU will be lusers... Because Kangaroo not adapted for FPGA

All others have the luck! That means that no need to have all required DP... With the luck you can solve #115 even on single CPU core  Roll Eyes

 Grin Grin Grin Grin Grin Grin Grin Grin Grin Grin Grin Grin Grin Grin Grin Grin Grin Grin

Buddy, you I think was say - all others have thr *uck ..... although of course this is unacceptable dirty and black humor, But this can bee throw with 90% proobabiity
sr. member
Activity: 443
Merit: 350
June 02, 2020, 02:38:13 PM
-snip-
Lets Ford will be winner  Grin But all who have no 20 GPU will be lusers... Because Kangaroo not adapted for FPGA

All others have the luck! That means that no need to have all required DP... With the luck you can solve #115 even on single CPU core  Roll Eyes
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
June 02, 2020, 02:00:50 PM
Good luck and you guys have way more computing power that you are willing to commit. Cool

I am going straight for the knowledge, world record, and bragging rights for secp256k1 130-bit private key (129-bit interval). But I only have 4TB of RAM and still working on how to minimize storage below 16bytes/point with data compression techniques. Grin

May the best win Cheesy

Lets Ford will be winner  Grin But all who have no 20 GPU will be lusers... Because Kangaroo not adapted for FPGA
sr. member
Activity: 462
Merit: 701
June 02, 2020, 01:33:54 PM
Good luck and you guys have way more computing power that you are willing to commit. Cool

I am going straight for the knowledge, world record, and bragging rights for secp256k1 130-bit private key (129-bit interval). But I only have 4TB of RAM and still working on how to minimize storage below 16bytes/point with data compression techniques. Grin

May the best win Cheesy
legendary
Activity: 1932
Merit: 2077
June 02, 2020, 01:25:13 PM
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)
member
Activity: 144
Merit: 10
June 02, 2020, 01:11:58 PM

How many Chrome tabs can you open with 4TB or RAM Smiley

Not on a single server, a distributed hash table on 8 servers with 512GB per server.
Jump to: