Bitcoin Forum
November 04, 2024, 01:07:33 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 ... 144 »
  Print  
Author Topic: Pollard's kangaroo ECDLP solver  (Read 58538 times)
arulbero
Legendary
*
Offline Offline

Activity: 1933
Merit: 2077


View Profile
June 02, 2020, 05:34:37 PM
 #661

Zielar solved #110 by merging 2 files of 2^29.55 DP each = 2^30.55 => DP25 => total of 2^(30.55 + 25) operations = ~2^(109/2+1) , a little bit after the average.

Ok, then:

total steps:  2^55.55 = 1.035 * 2*sqrt(N)  (3,5% after the average)

hash table: 2^55.55 / 2^25 = 2^30.55

how many kangaroos were used in parallel?

I suppose about 2^30, probably more; that means that each computing unit has generated only 1 DP on average?
Jean_Luc (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 696


View Profile
June 02, 2020, 05:47:26 PM
 #662

This is a race, we keep few settings secret.
We will probably end to fight after #120.
However now news from Zielar, he is probably sleeping Cheesy
COBRAS
Member
**
Offline Offline

Activity: 1014
Merit: 23


View Profile
June 02, 2020, 05:49:05 PM
 #663


We will probably end to fight after #120.



 Grin Grin Grin Grin Grin

[
HardwareCollector
Member
**
Offline Offline

Activity: 144
Merit: 10


View Profile
June 02, 2020, 06:04:22 PM
 #664

This is a race, we keep few settings secret.
We will probably end to fight after #120.
However now news from Zielar, he is probably sleeping Cheesy

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
WanderingPhilospher
Full Member
***
Offline Offline

Activity: 1204
Merit: 237

Shooters Shoot...


View Profile
June 02, 2020, 06:05:31 PM
 #665

Can you explain yourself better? What is 'Ygrid' ?

Ygrid is the second coordinate of the GPU thread array.
It affects performance. This is very useful for linear algebra because you can use thread coordinates to make fast matrix calculus.
In our case, this is just used to tune performance.

I was in weekend, Yesterday was also a day off in France, I restart the work today. I also have professional work to perform but I will continue to make update on github when I can for everybody. I will try to integrate ASAP the mods from  PatatasFritas and the support of -ws for the client mode. News from AndrewBrz who is progressing well with the OpenCL kernel.

Zielar solved #110 with official 1.8 and 1.9alpha for merging.

It'll be interesting to see what my Vega VIIs can do. They murder all the RTX cards when mining ethash (90 to 100 Mh/s compared to 40-55 Mh/s). I know mining is different but we shall see how they perform when it comes to this program. Hopefully Andrew has success, at least for himself.
Someone is working on opencl support ?
Yes, that link JLP posted to his Github, under the Issues tab, Optimization subject...AndrewBrz(?). He posted a pic of the  progress he has made so far.
WanderingPhilospher
Full Member
***
Offline Offline

Activity: 1204
Merit: 237

Shooters Shoot...


View Profile
June 02, 2020, 06:06:49 PM
 #666

This is a race, we keep few settings secret.
We will probably end to fight after #120.
However now news from Zielar, he is probably sleeping Cheesy

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

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

WanderingPhilospher
Full Member
***
Offline Offline

Activity: 1204
Merit: 237

Shooters Shoot...


View Profile
June 02, 2020, 06:11:08 PM
 #667

DP count is most important. You are running at DP 25, so it will take 2^57 (whatever expected group ops is for 115) - 2^25 (your DP setting) so roughly you want your DP count up to 2^32 to be getting close to solving.

I have files for DP 30.  So I need to get close to 2^27 to be getting close to solving. 2^57(expected ops) - 2^30(my DP setting) = 2^27 DP count .

To be precise, 2^57(expected ops) / 2^30(my DP setting) = 2^(57-30) = 2^27 DP count .

There are 3 phases in this algorithm:

phase 1)

to generate a collision, you need to form on average N couples of points (T, W) to get 1 couple with the same point, a collision (exploiting the birthday paradox)

that because in a space of N points there are N possible couples with the same point among N^2 possible couples, then the chance to get a collision each time you generate a couple (T, W) is N/N^2 = 1/N ,  thefor you need N tries to get a collision.

To form N couple, you need 2 lists of sqrt(N) points each (because sqrt(N) * sqrt(N) = N)

This is the heaviest part of the algorithm, 2*sqrt(N) steps; thefor the idea is to parallelize this task, and at this stage parallelization is ok, especially for the gpus.  


phase 2)

you cannot compare each couple of points you generate, because there are N possible combinations before to get a collision, too much;  

the idea is to choose each jump in such a way that the next point depends only by the current point, this trick makes an occasional collision between 2 kangaroos permanent and we don't need to check every point against all the others to know if a collision has happened.

To 'fix' a delay between the moment of the collision (after about 2*sqrt(N) steps) and the moment of the detection of the collision we store the distinguished points. On average a 30 bit distinguished point is met each 2^30 steps. Only then we can know if that kangaroo has collide with another one.

These phase is strange: if you are using a cpu, a delay of 2^30 steps is nothing, a single core of a cpu can perform 2^30 steps in a few minutes.

But for the slow gpu is not the same, like BitCrack noted:

That 2^27 figure assumes the average walk length is 2^30. The GPU works by doing many slow walks in parallel e.g. 60 million walks that do 20 iterations per second. At that rate, it will take 2^30 / 20 seconds = 1.7 years before any of the walks are 2^30. Your DP count is going to be a few powers of 2 higher than 27.

On the other hand, the choice of the distinguished points is not only about a delay, it is about the storage too, because we can't store 2*sqrt(N) points (if we could, we would use the BSGS algorithm, that is faster and that finds the key surely).


With a high DP value we realize a low frequent sampling, then we have few samples to store in the hash table, but we waste a lot of time with the gpu (overhead).

With a lower DP value we realize a high frequent sampling, but we have to deal with the limit of our RAM.

You can see at the DP value at this way too: how much you need to reduce the points (among the 2*sqrt(N) points generated) to put in the hash table ?

DP = 2^30 means you choose to reduce by a factor of 2^30 the storage of the 2^57 points needed the get a collision (2^57 / 2^30 = 2^27 DP in the hash table). But in this way you delay by 2^30 steps the detection of the collision (and you increase by a factor of 2^30  the waste of the computation power, 2^30 steps * number of kangaroos in parallel, all these steps are useless because they are realized after the collision has already happened)

In the Zielar's case, from what I understood, there were about 2^33 kangaroos in parallel and DP = 22, N = 2^109 then:

total steps:  2*sqrt(2^109) = 2^55.5

hash table: 2^55.5 / 2^22 = 2^33.5

number of steps generated by each computing unit in parallel: 2^55.5 / 2^33 = 2^22.5, then each computing unit has generated on average 1,4 kangaroo (1,4 walk from start to the end point, DP)  


phase 3)

When we know which wild kangaroo collides, if we don't know the distance covered by that kangaroo we only need to redo the steps of that kangaroo until the DP, and with a cpu this work can be rapidily finished.
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?
HardwareCollector
Member
**
Offline Offline

Activity: 144
Merit: 10


View Profile
June 02, 2020, 06:11:58 PM
 #668


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.
arulbero
Legendary
*
Offline Offline

Activity: 1933
Merit: 2077


View Profile
June 02, 2020, 06:25:13 PM
 #669

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)
Jean_Luc (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 696


View Profile
June 02, 2020, 06:33:54 PM
 #670

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
COBRAS
Member
**
Offline Offline

Activity: 1014
Merit: 23


View Profile
June 02, 2020, 07:00:50 PM
 #671

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

[
MrFreeDragon
Sr. Member
****
Offline Offline

Activity: 443
Merit: 350


View Profile
June 02, 2020, 07:38:13 PM
 #672

-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

COBRAS
Member
**
Offline Offline

Activity: 1014
Merit: 23


View Profile
June 02, 2020, 07:39:23 PM
 #673

-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

[
COBRAS
Member
**
Offline Offline

Activity: 1014
Merit: 23


View Profile
June 02, 2020, 07:59:05 PM
Last edit: June 02, 2020, 08:17:18 PM by COBRAS
 #674

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 ...

[
WanderingPhilospher
Full Member
***
Offline Offline

Activity: 1204
Merit: 237

Shooters Shoot...


View Profile
June 02, 2020, 08:18:00 PM
 #675

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.
Etar
Sr. Member
****
Offline Offline

Activity: 628
Merit: 312


View Profile
June 02, 2020, 08:34:46 PM
 #676

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.


COBRAS
Member
**
Offline Offline

Activity: 1014
Merit: 23


View Profile
June 02, 2020, 08:49:59 PM
 #677

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?

[
WanderingPhilospher
Full Member
***
Offline Offline

Activity: 1204
Merit: 237

Shooters Shoot...


View Profile
June 02, 2020, 08:58:10 PM
 #678

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. ?
WanderingPhilospher
Full Member
***
Offline Offline

Activity: 1204
Merit: 237

Shooters Shoot...


View Profile
June 02, 2020, 08:59:49 PM
 #679

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.
COBRAS
Member
**
Offline Offline

Activity: 1014
Merit: 23


View Profile
June 02, 2020, 09:02:49 PM
 #680

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.

[
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 ... 144 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!