Pollard's kangaroo ECDLP solver

[Siberian047]

Search speed will increase or not if you use:
- HDD, SSD, M.2 or DDR vertual disk?
-32 cores or 64 processor cores?

HDD speed doesn't matters.
If you using CPU then more cores => more threads => more speed.

We are talking about multithreading or we need to run 64 commands?
For example,  Brainflayer works only on one core.

[1714010027]

1714010027

[1714010027]

1714010027

[NotATether]

Search speed will increase or not if you use:
- HDD, SSD, M.2 or DDR vertual disk?
-32 cores or 64 processor cores?

HDD speed doesn't matters.
If you using CPU then more cores => more threads => more speed.

We are talking about multithreading or we need to run 64 commands?
For example,  Brainflayer works only on one core.

There is no need to run 64 different instances of Kangaroo at once, use the -t <number of threads> option to launch that many worker threads.

I wouldn't run Kangaroo on a virtual disk because of the overhead of running programs inside a VM, but other than that, since Kangaroo isn't a disk intensive program it doesn't matter which disk you run it on.

[Siberian047]

Search speed will increase or not if you use:
- HDD, SSD, M.2 or DDR vertual disk?
-32 cores or 64 processor cores?

HDD speed doesn't matters.
If you using CPU then more cores => more threads => more speed.

We are talking about multithreading or we need to run 64 commands?
For example,  Brainflayer works only on one core.

There is no need to run 64 different instances of Kangaroo at once, use the -t <number of threads> option to launch that many worker threads.

I wouldn't run Kangaroo on a virtual disk because of the overhead of running programs inside a VM, but other than that, since Kangaroo isn't a disk intensive program it doesn't matter which disk you run it on.

I ordered a computer with AMD Ryzen Threadripper PRO 3995WX 4.2 GHz and 256 GB of RAM. The motherboard ASUS Pro WS WRX80E-SAGE SE WIFI has 6 x PCI 16. I have not decided on the video cards yet.
Should get it in a week. I think to ask the help of specialists to help launch the program.
Do you think I will find support?

[NotATether]

I ordered a computer with AMD Ryzen Threadripper PRO 3995WX 4.2 GHz and 256 GB of RAM. The motherboard ASUS Pro WS WRX80E-SAGE SE WIFI has 6 x PCI 16. I have not decided on the video cards yet.
Should get it in a week. I think to ask the help of specialists to help launch the program.
Do you think I will find support?

Depends on what you mean by specialists. 9-to-5 computer technicians, or ordinary bitcointalk users?

I doubt technicians have heard anything about Kangaroo (some may not even know what bitcoin is!) so I would avoid that route. There is plenty of support on this thread to kelp you get Kangaroo up and running.

[WanderingPhilospher]

~

if 260 pubkeys in 110bit, then how much time it will take ?

The quick and easy answer would be to look at how long it took to solve #110...roughly 2 days.  You could take the 2 days and times that by 260 to get a quick and easy answer however, we know that the tames generated while searching for each pubkey would be used/valid for each subsequent pubkey. I think if one had 260 GPUs, each searching for 1 of the 260 pubkeys, and doing a daily merge/collision check, it would be much faster than the 2 x 260 days, but no way to be 100% certain.

Are all 260 in the 110 range?

16 out of 260 will be in 110bit range

Why are you searching 16 pubkeys at once in 110bit when there's only one pubkey for #110?

Runtime increases linearly with respect to the number of pubkeys, and when solving 1 pubkey, the runtime is already exponentially high, so you can't really find pubkeys quicker by batching them together in the same command invocation.

Brainless is not looking for pubkey #110; he is looking for #120's pubkey inside 2^110 range via shifting #120's pubkey.  Ultimately he has shrank the range by a factor of 2^10 = 1024 but needs to run the program for each pubkey or integrate runs with the 260 pubkeys.   

[WanderingPhilospher]

Search speed will increase or not if you use:
- HDD, SSD, M.2 or DDR vertual disk?
-32 cores or 64 processor cores?

The only thing you mentioned that will speed up search is the number of cores. Each core you run has 1024 kangaroos; you can change that by compiling your self. So if you run 64 cores versus 32 then you have doubled the amount of kangaroos running at once.

I have been interested in what a quality AMD processor (especially a threadripper) can do so please post your MKey/s once you have it set up and running.

[Siberian047]

Search speed will increase or not if you use:
- HDD, SSD, M.2 or DDR vertual disk?
-32 cores or 64 processor cores?

The only thing you mentioned that will speed up search is the number of cores. Each core you run has 1024 kangaroos; you can change that by compiling your self. So if you run 64 cores versus 32 then you have doubled the amount of kangaroos running at once.

I have been interested in what a quality AMD processor (especially a threadripper) can do so please post your MKey/s once you have it set up and running.

ok, let's do it. I understand that the exchange of information is a golden value.

[Siberian047]

Is there a threat from new GPUs blocking mining?
For example, this video katrta with the addition of LHR.
EVGA GeForce RTX 3070 Ti FTW3 ULTRA (LHR)

[unclevito]

~

if 260 pubkeys in 110bit, then how much time it will take ?

The quick and easy answer would be to look at how long it took to solve #110...roughly 2 days.  You could take the 2 days and times that by 260 to get a quick and easy answer however, we know that the tames generated while searching for each pubkey would be used/valid for each subsequent pubkey. I think if one had 260 GPUs, each searching for 1 of the 260 pubkeys, and doing a daily merge/collision check, it would be much faster than the 2 x 260 days, but no way to be 100% certain.

Are all 260 in the 110 range?

16 out of 260 will be in 110bit range

Why are you searching 16 pubkeys at once in 110bit when there's only one pubkey for #110?

So how do you shift a public key down to another keyspace?

Runtime increases linearly with respect to the number of pubkeys, and when solving 1 pubkey, the runtime is already exponentially high, so you can't really find pubkeys quicker by batching them together in the same command invocation.

Brainless is not looking for pubkey #110; he is looking for #120's pubkey inside 2^110 range via shifting #120's pubkey.  Ultimately he has shrank the range by a factor of 2^10 = 1024 but needs to run the program for each pubkey or integrate runs with the 260 pubkeys.   

[WanderingPhilospher]

Is there a threat from new GPUs blocking mining?
For example, this video katrta with the addition of LHR.
EVGA GeForce RTX 3070 Ti FTW3 ULTRA (LHR)

The LHR = Low(er) Hash Rate. I know these cards mine ethash (ethereum) at lower rate but I am not sure about other algos.

So yes, a card that has LHR on it will not mine as good as a non LHR card.

[bigvito19]

Brainless is not looking for pubkey #110; he is looking for #120's pubkey inside 2^110 range via shifting #120's pubkey.  Ultimately he has shrank the range by a factor of 2^10 = 1024 but needs to run the program for each pubkey or integrate runs with the 260 pubkeys.   

How do you shift or shrink a range? I think I seen that before.

[WanderingPhilospher]

Brainless is not looking for pubkey #110; he is looking for #120's pubkey inside 2^110 range via shifting #120's pubkey.  Ultimately he has shrank the range by a factor of 2^10 = 1024 but needs to run the program for each pubkey or integrate runs with the 260 pubkeys.   

How do you shift or shrink a range? I think I seen that before.

You subtract from the original pubkey you are searching for.

[NotATether]

Brainless is not looking for pubkey #110; he is looking for #120's pubkey inside 2^110 range via shifting #120's pubkey.  Ultimately he has shrank the range by a factor of 2^10 = 1024 but needs to run the program for each pubkey or integrate runs with the 260 pubkeys.   

I believe that for more chances to find a private key, you could shift the range down even more, like to 2^70 but you have 2 million targets.

2 million is about 2^21 targets and birthday reduces the probability of a hit to 2^35, 50% of the keyspace which makes an average of almost 2^21 * 2^35 = nearly 2^56 operations. That's lower than 260 keys at 2^110 keyspace. So I think that it's possible to optimize how much you shift down by adjusting the number of targets and the resulting keyspace size to minimize ops = keyspace/2 + log2_numberoftargets.

[WanderingPhilospher]

Brainless is not looking for pubkey #110; he is looking for #120's pubkey inside 2^110 range via shifting #120's pubkey.  Ultimately he has shrank the range by a factor of 2^10 = 1024 but needs to run the program for each pubkey or integrate runs with the 260 pubkeys.   

I believe that for more chances to find a private key, you could shift the range down even more, like to 2^70 but you have 2 million targets.

2 million is about 2^21 targets and birthday reduces the probability of a hit to 2^35, 50% of the keyspace which makes an average of almost 2^21 * 2^35 = nearly 2^56 operations. That's lower than 260 keys at 2^110 keyspace. So I think that it's possible to optimize how much you shift down by adjusting the number of targets and the resulting keyspace size to minimize ops = keyspace/2 + log2_numberoftargets.

The problem is if you were to shift #120 down to 2^70 range, that means you'd have to check 2^50 targets (120 - 70 = 50); which obviously makes it impossible to check that many targets.  How did you come up with 2 million targets?

[unclevito]

Brainless is not looking for pubkey #110; he is looking for #120's pubkey inside 2^110 range via shifting #120's pubkey.  Ultimately he has shrank the range by a factor of 2^10 = 1024 but needs to run the program for each pubkey or integrate runs with the 260 pubkeys.   

I believe that for more chances to find a private key, you could shift the range down even more, like to 2^70 but you have 2 million targets.

2 million is about 2^21 targets and birthday reduces the probability of a hit to 2^35, 50% of the keyspace which makes an average of almost 2^21 * 2^35 = nearly 2^56 operations. That's lower than 260 keys at 2^110 keyspace. So I think that it's possible to optimize how much you shift down by adjusting the number of targets and the resulting keyspace size to minimize ops = keyspace/2 + log2_numberoftargets.

The problem is if you were to shift #120 down to 2^70 range, that means you'd have to check 2^50 targets (120 - 70 = 50); which obviously makes it impossible to check that many targets.  How did you come up with 2 million targets?

2^50 is
one quadrillion ,
one hundred twenty five trillion ,
eight hundred ninety nine billion ,
nine hundred six million ,
eight hundred forty two thousand ,
six hundred twenty four  That would make a text file over 100 gb, what text editor would open that to see what you need to add or subtract to get the answer

[Siberian047]

Brainless is not looking for pubkey #110; he is looking for #120's pubkey inside 2^110 range via shifting #120's pubkey.  Ultimately he has shrank the range by a factor of 2^10 = 1024 but needs to run the program for each pubkey or integrate runs with the 260 pubkeys.   

I believe that for more chances to find a private key, you could shift the range down even more, like to 2^70 but you have 2 million targets.

2 million is about 2^21 targets and birthday reduces the probability of a hit to 2^35, 50% of the keyspace which makes an average of almost 2^21 * 2^35 = nearly 2^56 operations. That's lower than 260 keys at 2^110 keyspace. So I think that it's possible to optimize how much you shift down by adjusting the number of targets and the resulting keyspace size to minimize ops = keyspace/2 + log2_numberoftargets.

The problem is if you were to shift #120 down to 2^70 range, that means you'd have to check 2^50 targets (120 - 70 = 50); which obviously makes it impossible to check that many targets.  How did you come up with 2 million targets?

2^50 is
one quadrillion ,
one hundred twenty five trillion ,
eight hundred ninety nine billion ,
nine hundred six million ,
eight hundred forty two thousand ,
six hundred twenty four  That would make a text file over 100 gb, what text editor would open that to see what you need to add or subtract to get the answer

2^50= 1.125.899.906.842.624

[WanderingPhilospher]

Brainless is not looking for pubkey #110; he is looking for #120's pubkey inside 2^110 range via shifting #120's pubkey.  Ultimately he has shrank the range by a factor of 2^10 = 1024 but needs to run the program for each pubkey or integrate runs with the 260 pubkeys.   

I believe that for more chances to find a private key, you could shift the range down even more, like to 2^70 but you have 2 million targets.

2 million is about 2^21 targets and birthday reduces the probability of a hit to 2^35, 50% of the keyspace which makes an average of almost 2^21 * 2^35 = nearly 2^56 operations. That's lower than 260 keys at 2^110 keyspace. So I think that it's possible to optimize how much you shift down by adjusting the number of targets and the resulting keyspace size to minimize ops = keyspace/2 + log2_numberoftargets.

The problem is if you were to shift #120 down to 2^70 range, that means you'd have to check 2^50 targets (120 - 70 = 50); which obviously makes it impossible to check that many targets.  How did you come up with 2 million targets?

2^50 is
one quadrillion ,
one hundred twenty five trillion ,
eight hundred ninety nine billion ,
nine hundred six million ,
eight hundred forty two thousand ,
six hundred twenty four  That would make a text file over 100 gb, what text editor would open that to see what you need to add or subtract to get the answer

Opening it isn't the problem.  It would take a long time just for the program to write all of those public keys.

[NotATether]

The problem is if you were to shift #120 down to 2^70 range, that means you'd have to check 2^50 targets (120 - 70 = 50); which obviously makes it impossible to check that many targets.  How did you come up with 2 million targets?

I thought you could choose any number of targets to check, at the expense of the likelihood of you finding a match when searching for less targets.

[WanderingPhilospher]

The problem is if you were to shift #120 down to 2^70 range, that means you'd have to check 2^50 targets (120 - 70 = 50); which obviously makes it impossible to check that many targets.  How did you come up with 2 million targets?

I thought you could choose any number of targets to check, at the expense of the likelihood of you finding a match when searching for less targets.

No. If you are shifting a pubkey down, you can either subtract or divide.  Simple explanation (for those who have asked as well):

Subtraction only gets you so far, if you know what range the key is in, it can help you speed things up by dropping down a few ranges. 
Let's say our key is:
CF36F0

If I know the key lies in the 2^24 range of 800000:FFFFFF, then I know I can be safe and at least subtract 800000. Now the range shifts to 0:7FFFFF
Well let's say I know it is somewhere in the C00000:FFFFFF range. I can safely subtract C00000. Now the range shifts to 0:3FFFFF
But let's say I don't know where the key is but I am 80% sure it starts with a D. So I subtract D00000.  Well, now the key is back around the wheel in no man's land because it won't lie between 0:2FFFFF. D00000-CF36F0 = some negative key.

Now, you can also divide a key.  If we know our key lies in the 2^24 range and want to drop it down to the 2^14 range, we can divide by 1024 (2^10) 2^24 - 2^10 = 2^14
But now we have 1024 pubkeys that we have to search for but 2^1000% one of those 1024 pubkeys is in the 2^14 range.

So if one wanted to drop from 2^120 down to 2^70 range, well....that's a lot of pubkeys to search for.

[unclevito]

The problem is if you were to shift #120 down to 2^70 range, that means you'd have to check 2^50 targets (120 - 70 = 50); which obviously makes it impossible to check that many targets.  How did you come up with 2 million targets?

I thought you could choose any number of targets to check, at the expense of the likelihood of you finding a match when searching for less targets.

No. If you are shifting a pubkey down, you can either subtract or divide.  Simple explanation (for those who have asked as well):

Subtraction only gets you so far, if you know what range the key is in, it can help you speed things up by dropping down a few ranges.  
Let's say our key is:
CF36F0

If I know the key lies in the 2^24 range of 800000:FFFFFF, then I know I can be safe and at least subtract 800000. Now the range shifts to 0:7FFFFF
Well let's say I know it is somewhere in the C00000:FFFFFF range. I can safely subtract C00000. Now the range shifts to 0:3FFFFF
But let's say I don't know where the key is but I am 80% sure it starts with a D. So I subtract D00000.  Well, now the key is back around the wheel in no man's land because it won't lie between 0:2FFFFF. D00000-CF36F0 = some negative key.

Now, you can also divide a key.  If we know our key lies in the 2^24 range and want to drop it down to the 2^14 range, we can divide by 1024 (2^10) 2^24 - 2^10 = 2^14
But now we have 1024 pubkeys that we have to search for but 2^1000% one of those 1024 pubkeys is in the 2^14 range.

So if one wanted to drop from 2^120 down to 2^70 range, well....that's a lot of pubkeys to search for.

to be clear to me you are saying divide the uncompressed public key (converted to decimal)  by 2 to the power of the number of steps down or can you use the compressed key converted to decimal divided by 1024 if 10 steps then the amount back to hex as the new public key for the lower keyspace?