Quote from: unclevito on Today at 04:52:33 PM

Quote from: WanderingPhilospher on Today at 01:06:59 PM

Quote from: NotATether on Today at 12:18:47 PM

Quote from: WanderingPhilospher on June 22, 2021, 04:54:01 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.

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.