Pollard's kangaroo ECDLP solver

[Robert_BIT]

The .exe from a.a works fine on a modest GPU, haven't tested yet on higher specs. Thanks again for compiling!

One question:

Any particular reason why the CPU usage jumps and stays to 100% as it runs further and further? This happens with Jean Luc's version too. The temp is normal btw. Maybe is just my machine but I was curious if it's something in the code that makes use of the CPU as well as GPU.

[1713284326]

1713284326

[1713284326]

1713284326

[1713284326]

1713284326

[NotATether]

Anybody else see this:

~

Damn it, I didn't get the DP size formatting correct on Windows either. 

Yeah this is a known bug https://github.com/ZenulAbidin/Kangaroo-256/issues/3 which also appears to affect how speed is displayed too, I have to investigate this further when I have time.

[Robert_BIT]

I am not too sure how to calculate this, if someone can help me.

We have at the Uni one NVIDIA DGX A100

It packs 5 petaFLOPS, eight A100 GPUs with 320GB of GPU memory.

Realistically, if we get permission to run it 24/7 (which I doubt lol) for the 120 key, how long would it take? Is it feasible? And more important, would the Kangaroo even work on it?

[NotATether]

I am not too sure how to calculate this, if someone can help me.

We have at the Uni one NVIDIA DGX A100

It packs 5 petaFLOPS, eight A100 GPUs with 320GB of GPU memory.

Realistically, if we get permission to run it 24/7 (which I doubt lol) for the 120 key, how long would it take? Is it feasible? And more important, would the Kangaroo even work on it?

I remember WanderingPhilosipher saying that 256 V100's that were running simultaneously for several years only exhausted 15% of #120, and regardless of how faster an A100 is versus a V100, 8 of them definitely won't make the cut.

And you also have to worry about making Kangaroo dump the private key to a file (if it even supports that without stdout redirects), or you'll lose the key if your terminal session is disconnected.

[Robert_BIT]

Several years? Wow.

On GitHub here https://github.com/JeanLucPons/Kangaroo it says 2 months with 256 V100's. Must be wrong then - someone ought to correct that.  

I'll also ask our researchers and get back on this.

[WanderingPhilospher]

I am not too sure how to calculate this, if someone can help me.

We have at the Uni one NVIDIA DGX A100

It packs 5 petaFLOPS, eight A100 GPUs with 320GB of GPU memory.

Realistically, if we get permission to run it 24/7 (which I doubt lol) for the 120 key, how long would it take? Is it feasible? And more important, would the Kangaroo even work on it?

I remember WanderingPhilosipher saying that 256 V100's that were running simultaneously for several years only exhausted 15% of #120, and regardless of how faster an A100 is versus a V100, 8 of them definitely won't make the cut.

And you also have to worry about making Kangaroo dump the private key to a file (if it even supports that without stdout redirects), or you'll lose the key if your terminal session is disconnected.

Negative, that was for #64, using Bitcrack...not #120 using Kangaroo.  And it's the #64 pool that has been set up for a few years and I know that the 256 V100s have ran for weeks at a time along with other cards. Last I checked it was around 15% of total keys checked for #64.

I do not know if Zielar is running his V100s at #120.

[WanderingPhilospher]

I am not too sure how to calculate this, if someone can help me.

We have at the Uni one NVIDIA DGX A100

It packs 5 petaFLOPS, eight A100 GPUs with 320GB of GPU memory.

Realistically, if we get permission to run it 24/7 (which I doubt lol) for the 120 key, how long would it take? Is it feasible? And more important, would the Kangaroo even work on it?

Just run them and see how long the program tells you til it solves. The estimated time is pretty close to being accurate. No way to know since I don't know the speed and grid size of the A100s.

[Robert_BIT]

Well it seems that each A100 is about 2.5 - 3 times faster than V100 so I won't even try for now. I have to ask my professor and it's going to be a pain accessing it anyway.

But it's interesting how computing power is basically the only thing required. I guess is just a matter of time until someone with access to a supercomputer might give it a try...

[NotATether]

Well it seems that each A100 is about 2.5 - 3 times faster than V100 so I won't even try for now. I have to ask my professor and it's going to be a pain accessing it anyway.

But it's interesting how computing power is basically the only thing required. I guess is just a matter of time until someone with access to a supercomputer might give it a try...

...and then get arrested like this guy? https://www.itnews.com.au/news/csiro-it-contractor-spared-jail-for-mining-monero-on-supercomputer-553535 

On a more serious note, the software will have to improve to a level where it's not experimental before people start investing their resources into it.

[WanderingPhilospher]

Well it seems that each A100 is about 2.5 - 3 times faster than V100 so I won't even try for now. I have to ask my professor and it's going to be a pain accessing it anyway.

But it's interesting how computing power is basically the only thing required. I guess is just a matter of time until someone with access to a supercomputer might give it a try...

...and then get arrested like this guy? https://www.itnews.com.au/news/csiro-it-contractor-spared-jail-for-mining-monero-on-supercomputer-553535 

On a more serious note, the software will have to improve to a level where it's not experimental before people start investing their resources into it.

What was the speed of your version?  Wasn't it a lot slower than Jean Luc's?

So with your version people can store 256 bits in the work files, right? Is that the only difference?

If so, I am not sure why people are using yours, especially if it is slower than the original.  If it is faster, I still don't know why they would use it for the puzzle since it will require more RAM/storage space.

Please enlighten me NotATether...I truly can't remember the speed and the differences in your version.

[Robert_BIT]

Well it seems that each A100 is about 2.5 - 3 times faster than V100 so I won't even try for now. I have to ask my professor and it's going to be a pain accessing it anyway.

But it's interesting how computing power is basically the only thing required. I guess is just a matter of time until someone with access to a supercomputer might give it a try...

...and then get arrested like this guy? https://www.itnews.com.au/news/csiro-it-contractor-spared-jail-for-mining-monero-on-supercomputer-553535 

On a more serious note, the software will have to improve to a level where it's not experimental before people start investing their resources into it.

Agree 100%. All sorts of people are resorting to crime, using resources without authorization, simply for profit. The reality is that it may very well work for a while but chances are statistically high that they will get a visit from the authorities. Anything related to crypto is by design built to leave 'some' traces. It's not a good business to steal computing power - whether that's for mining, things like this puzzle or anything related to crypto, really. They're just too many variables involved in terms of security and I'm not really sure who's dumb enough to think they will get away with it.   

[bigvito19]

So what does 256 bits look like stored in a work file, I need to see an example.

[WanderingPhilospher]

So what does 256 bits look like stored in a work file, I need to see an example.

AF4560D2458D74B963C5F3B7FD7A65ECF6A860C23BD1AC97B3A1121B2BC657D8 F1978DCDCDCDCC8D76C8C5DC5D85CD5C765C5D7C57D5C7D5C57D5C75D7C57D5C

256bits (space) 256bits

[jmizarob]

Out of curiosity, I was testing a range 0-FFFFFFFFFFFF and found the private key very quickly. I then proceeded to test the next range 1000000000000-1FFFFFFFFFFFF of equivalent size but with a public key of the first keyspace. It still managed to solve for the private key, even though the private key wasn't in the range provided. It took about 5 minutes. Why is that?

[GoldTiger69]

Out of curiosity, I was testing a range 0-FFFFFFFFFFFF and found the private key very quickly. I then proceeded to test the next range 1000000000000-1FFFFFFFFFFFF of equivalent size but with a public key of the first keyspace. It still managed to solve for the private key, even though the private key wasn't in the range provided. It took about 5 minutes. Why is that?

Maybe because the range is very small? And how come it found a key that wasn't there? That's a contadiction

[WanderingPhilospher]

Out of curiosity, I was testing a range 0-FFFFFFFFFFFF and found the private key very quickly. I then proceeded to test the next range 1000000000000-1FFFFFFFFFFFF of equivalent size but with a public key of the first keyspace. It still managed to solve for the private key, even though the private key wasn't in the range provided. It took about 5 minutes. Why is that?

Maybe because the range is very small? And how come it found a key that wasn't there? That's a contadiction

A lesser key is always in a larger range.

lesser range = 0-FFFFFFFFFFFF

greater range = 1000000000000-1FFFFFFFFFFFF

Let's say priv key to pub key is 3103FFCB8A82

This program always starts from 0. So if user enters the range of:
1000000000000:1FFFFFFFFFFFF

the program automatically subtracts the beginning range and shifts the pub key accordingly, in this case it subtracts and shifts by 1000000000000; so the program is actually searching from:
0:FFFFFFFFFFFF

If pubkey is found, the program calculates key like so: Tame D - Wild D + (original beginning range) 1000000000000

[jmizarob]

Out of curiosity, I was testing a range 0-FFFFFFFFFFFF and found the private key very quickly. I then proceeded to test the next range 1000000000000-1FFFFFFFFFFFF of equivalent size but with a public key of the first keyspace. It still managed to solve for the private key, even though the private key wasn't in the range provided. It took about 5 minutes. Why is that?

Maybe because the range is very small? And how come it found a key that wasn't there? That's a contadiction

A lesser key is always in a larger range.

lesser range = 0-FFFFFFFFFFFF

greater range = 1000000000000-1FFFFFFFFFFFF

Let's say priv key to pub key is 3103FFCB8A82

This program always starts from 0. So if user enters the range of:
1000000000000:1FFFFFFFFFFFF

the program automatically subtracts the beginning range and shifts the pub key accordingly, in this case it subtracts and shifts by 1000000000000; so the program is actually searching from:
0:FFFFFFFFFFFF

If pubkey is found, the program calculates key like so: Tame D - Wild D + (original beginning range) 1000000000000

Makes perfect sense! Just not very efficient for finding that lesser private key. I wonder if that could be optimized?

[WanderingPhilospher]

Out of curiosity, I was testing a range 0-FFFFFFFFFFFF and found the private key very quickly. I then proceeded to test the next range 1000000000000-1FFFFFFFFFFFF of equivalent size but with a public key of the first keyspace. It still managed to solve for the private key, even though the private key wasn't in the range provided. It took about 5 minutes. Why is that?

Maybe because the range is very small? And how come it found a key that wasn't there? That's a contadiction

A lesser key is always in a larger range.

lesser range = 0-FFFFFFFFFFFF

greater range = 1000000000000-1FFFFFFFFFFFF

Let's say priv key to pub key is 3103FFCB8A82

This program always starts from 0. So if user enters the range of:
1000000000000:1FFFFFFFFFFFF

the program automatically subtracts the beginning range and shifts the pub key accordingly, in this case it subtracts and shifts by 1000000000000; so the program is actually searching from:
0:FFFFFFFFFFFF

If pubkey is found, the program calculates key like so: Tame D - Wild D + (original beginning range) 1000000000000

Makes perfect sense! Just not very efficient for finding that lesser private key. I wonder if that could be optimized?

The optimization is...don't search in a larger range for a key you know is in a smaller range, like you did.  Like you said, when you searched in the smaller range it was found rather quick.
But the good news is, you know the program can find a key in a lesser range, even if your inputted range is greater.
Try running the program again with greater range with lesser key and see if it takes 5 minutes every time.
Remember, Pollard's Kangaroo/Lambda is designed to find a key in a known range (a, b).

[bigvito19]

I got an RTX 2060 GPU. I was testing it using Jean_Luc's vanitygen and kangaroo. With the vanitygen the speed was at least +900 MKeys and the kangaroo speed was doing between 500 and 600 MKeys. Is this normal or do I have the wrong configuration with kangaroo?

[NotATether]

I got an RTX 2060 GPU. I was testing it using Jean_Luc's vanitygen and kangaroo. With the vanitygen the speed was at least +900 MKeys and the kangaroo speed was doing between 500 and 600 MKeys. Is this normal or do I have the wrong configuration with kangaroo?

Sounds about right to me. Vanitysearch is always going to appear faster than Kangaroo because of the former's use of endomorphisms to check several privkeys at once.