Pollard's kangaroo ECDLP solver - page 51.

unclevito

jr. member

Activity: 76

Merit: 4

Quote from: COBRAS on June 26, 2021, 03:16:03 AM

Quote from: NotATether on June 24, 2021, 12:55:42 AM

Quote from: WanderingPhilospher on June 23, 2021, 04:07:33 PM

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.

Subtraction is clear to me, and so is division somewhat, but why the need to search 1024 pubkeys after dividing by that number? What will all their values be set to, apart from the one pubkey which is still its original value?

This is realy woked ? for ex, If I substract 128 pubkey from 255 pubkey, I will get 128 pubkey ?

Substarct from pubkey simple numder is real SHIT !!! Ths not worked and waste MANY MONEY,NERVOUS AND TIME. Agree ?

if it was that easy all would have been found 2 years ago. This is a board of ideas so if it makes sense to you you try it if it does not then don't try it, that is why I come to this board for ideas and advice. As far as I know no one is charging for their ideas so where is the Scam? Bad choice of words.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: COBRAS on June 26, 2021, 03:16:03 AM

This is realy woked ? for ex, If I substract 128 pubkey from 255 pubkey, I will get 128 pubkey ?

Erm no, read WanderingPhilosipher's reply above. Subtraction is good for clearing out values within a keyspace exponent, but for actually reducing the magnitude of the keyspace, division does the job.

Division deletes values on the number line. E.g something divided by 8 lets you use 8 or 16 or 24... from the original number line, (given a new number line of 1, 2, 3, ... as quotients) the 9-15 integers become "inaccessible", so it's possible the private key might be unreadable (because of impossible decimal remainder), meaning when you divide the keyspace by x number, not only do you have to find pubkey/x, you must also search (pubkey+1)/x, (pubkey+2)/x, ..., (pubkey+x-1)/x, because only one of these will hit the original private key.

COBRAS

member

Activity: 873

Merit: 22

$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk

Quote

(2^10) 2^24 - 2^10 = 2^14

And respected looser's !!! Yeas, THIS IS FUCKIND SHIT AGAIN !!! Brainless guru thant fuck us again !!!

( 2^24 - 2^10) = fffc00

2^14 = 4000(in hex)

This is magic ? No, fuck, this no magic.No, this mean I apologise what Something is try fuck us again. Grin

Agree with me my friends ?

COBRAS

member

Activity: 873

Merit: 22

$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk

Quote from: NotATether on June 24, 2021, 12:55:42 AM

Quote from: WanderingPhilospher on June 23, 2021, 04:07:33 PM

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.

Subtraction is clear to me, and so is division somewhat, but why the need to search 1024 pubkeys after dividing by that number? What will all their values be set to, apart from the one pubkey which is still its original value?

This is realy woked ? for ex, If I substract 128 pubkey from 255 pubkey, I will get 128 pubkey ?

Substarct from pubkey simple numder is real SHIT !!! Ths not worked and waste MANY MONEY,NERVOUS AND TIME. Agree ?

_Counselor

member

Activity: 110

Merit: 61

Quote from: NotATether on June 24, 2021, 12:55:42 AM

Quote from: WanderingPhilospher on June 23, 2021, 04:07:33 PM

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.

Subtraction is clear to me, and so is division somewhat, but why the need to search 1024 pubkeys after dividing by that number? What will all their values be set to, apart from the one pubkey which is still its original value?

Because you dont know whether the secret key is divisible without remainder by 1024. If not divisible, result will be lie somewhere on an unknown segment of elliptic curve.

Therefore, to reduce key in such a way you have to divide by 1024 not only secret key, but also key+1 key+2 ... key+1023, one of which will be divisible by 1024 and lie in the correct reduced range.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: WanderingPhilospher on June 23, 2021, 04:07:33 PM

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.

Subtraction is clear to me, and so is division somewhat, but why the need to search 1024 pubkeys after dividing by that number? What will all their values be set to, apart from the one pubkey which is still its original value?

WanderingPhilospher

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: unclevito on June 23, 2021, 04:31:43 PM

Quote from: WanderingPhilospher on June 23, 2021, 04:07:33 PM

Quote from: NotATether on June 23, 2021, 03:28:21 PM

Quote from: WanderingPhilospher on June 23, 2021, 08:06:59 AM

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?

No, it's not regular division, it's a lot of mod p this mod p that.
But when done, you must use uncompressed because you use the x and y coord.

Brainless may be able to explain it better. He may have some tips or tricks as well.

unclevito

jr. member

Activity: 76

Merit: 4

Quote from: WanderingPhilospher on June 23, 2021, 04:07:33 PM

Quote from: NotATether on June 23, 2021, 03:28:21 PM

Quote from: WanderingPhilospher on June 23, 2021, 08:06:59 AM

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?

WanderingPhilospher

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: NotATether on June 23, 2021, 03:28:21 PM

Quote from: WanderingPhilospher on June 23, 2021, 08:06:59 AM

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.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: WanderingPhilospher on June 23, 2021, 08:06:59 AM

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

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: unclevito on June 23, 2021, 11:52:33 AM

Quote from: WanderingPhilospher on June 23, 2021, 08:06:59 AM

Quote from: NotATether on June 23, 2021, 07:18:47 AM

Quote from: WanderingPhilospher on June 22, 2021, 11:54:01 AM

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.

Siberian047

newbie

Activity: 11

Merit: 0

Quote from: unclevito on June 23, 2021, 11:52:33 AM

Quote from: WanderingPhilospher on June 23, 2021, 08:06:59 AM

Quote from: NotATether on June 23, 2021, 07:18:47 AM

Quote from: WanderingPhilospher on June 22, 2021, 11:54:01 AM

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

unclevito

jr. member

Activity: 76

Merit: 4

Quote from: WanderingPhilospher on June 23, 2021, 08:06:59 AM

Quote from: NotATether on June 23, 2021, 07:18:47 AM

Quote from: WanderingPhilospher on June 22, 2021, 11:54:01 AM

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

WanderingPhilospher

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: NotATether on June 23, 2021, 07:18:47 AM

Quote from: WanderingPhilospher on June 22, 2021, 11:54:01 AM

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?

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: WanderingPhilospher on June 22, 2021, 11:54:01 AM

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

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: bigvito19 on June 22, 2021, 03:55:11 PM

Quote from: WanderingPhilospher on June 22, 2021, 11:54:01 AM

Quote from: NotATether on June 22, 2021, 04:18:03 AM

Quote from: brainless on June 21, 2021, 11:11:45 AM

Quote from: WanderingPhilospher on June 21, 2021, 11:07:41 AM

Quote from: brainless on June 21, 2021, 06:00:45 AM

Quote from: WanderingPhilospher on June 18, 2021, 05:29:55 PM

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.

bigvito19

full member

Activity: 706

Merit: 111

Quote from: WanderingPhilospher on June 22, 2021, 11:54:01 AM

Quote from: NotATether on June 22, 2021, 04:18:03 AM

Quote from: brainless on June 21, 2021, 11:11:45 AM

Quote from: WanderingPhilospher on June 21, 2021, 11:07:41 AM

Quote from: brainless on June 21, 2021, 06:00:45 AM

Quote from: WanderingPhilospher on June 18, 2021, 05:29:55 PM

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

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: Siberian047 on June 22, 2021, 12:49:04 PM

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.

unclevito

jr. member

Activity: 76

Merit: 4

Quote from: WanderingPhilospher on June 22, 2021, 11:54:01 AM

Quote from: NotATether on June 22, 2021, 04:18:03 AM

Quote from: brainless on June 21, 2021, 11:11:45 AM

Quote from: WanderingPhilospher on June 21, 2021, 11:07:41 AM

Quote from: brainless on June 21, 2021, 06:00:45 AM

Quote from: WanderingPhilospher on June 18, 2021, 05:29:55 PM

~

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.

Siberian047

newbie

Activity: 11

Merit: 0

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)

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