Bro, try downgrade range for 5bits, from 120 to 115, you get f 32 public keys with guaranteed 1 pubkey in range 115.

yes... but I think 1000 pubkeys in range 100 will be faster then 1 in 120 ?

If you downgrade to range 100, you will have ~1,000,000 pubkeys and only 1 of them is the right one.
You would have to calculate far more than the original one in #120.

YeEyYas  Bro, not 1000 for 10 bits but 1000000 = 32(120->115)*32(115-110) etc...

Why run the test when you have an average/expected run time calculation?
Running your test, you would have to set -m option to 1.x or 2.x to ensure you find key if it is the key that is in the range; expected/average can sometimes go over the 50% mark.
You can run parallel only if you have 32 GPUs and run a different program.

Granted, if the key is in the 0 or 1 spot, you would definitely save some minutes at 65 bit range, but 120 bit range is a different monster, way bigger bit range and who wants to chance it?

Guys, take a look at this: https://link.springer.com/content/pdf/10.1007/s11227-020-03441-5.pdf

A faster modular multiplication implementation for the P-192 curve.

Granted this is the wrong curve, but it has the same general formula y2 = x3+ax+b, so all that theoretically has to be done is to extend the summations to a few extra terms (they'll just be 32 words instead of 24, which means a 32x32 word multiplication size instead of 24x24) and accommodate for the missing ax.

E.g. where it defines range shifted representation (RSR) of a large number, which it uses in the algorithm:


We can just replace it with this:


(x, y, z summation terms are all between 0 and 255 inclusive)

Then the rest of the modular multiplication follows suit.

They say it's 26% faster than the usual ECC multiplication algorithm. I wonder if this representation also handles modular addition well. If it does, then we got ourselves a faster way to do modular arithmetic.

The study was carried out on some 8-bit embedded machine. Modern pipelines stuff 64 bits in a register so we may even be able to reduce the number of RSR words by a factor of 8 i.e. only 2 x and y words and 4 z words (and ovbiously the maximum range of each word increases proportionally).

I think all modern methods about speed up SECP operation include point addition and multiplication etc in this article(codes included) https://paulmillr.com/posts/noble-secp256k1-fast-ecc/ if use a Jacobian coordinates with a endomorphism  and windows method/

I think this is an interesting method, if we do not forget that brute forse is jast addition of points, multiplication and comparison of the result with the target pubkey is an endomorphism and a splitting point into 2 parts, and the brute 2 parts separately.... but due to the fact that many people here, like me, are a bit lazy, all the methods are being implemented too slowly.

Hello .
Someone can suggest.
How to write a program in python for taking away and adding the Public key from the public key.
An example.
031656894a2e404e652e3a2b368c7df820b0e92fe32529c41931a9f7b234457d5b (d456ba310f)   - 022fa21d1cea4bc1f9911a9d501e3d8b3c97d15aaa76a63fecd0d529b9ef2e22f5    (23fa540bcd)


result
0297539272d59d6e75488df9a5628e7b0efc03b4fec79de246ac116ae40c05225a (B05C662542)


I get everything, but not this result.
Also, with addition, the result is not correct.

I would be grateful if you indicate where to find the corresponding sketch in python.
Sincerely .

Yes, I used the program almost like yours is written below.
But I compared it with yours and noticed a fundamental mistake.
And now everything works.
I am very grateful to you for your help.
I hope that my way of calculation is correct and I can share my work with here.

@NotATether

i have 300 public keys and loading one by one in this script is painful. can you please modify this script to get a file of public keys and process one by one all.