Though it's trivial to be done, such gaps can become problematic (range isn't covered, all pvt keys need to be multiplied by some size, etc.). If you want some type of "spreading", the threads already start off from evenly-spaced subregions (you can see that as the callback returns key offsets in batches of different sequences).

The code should also run faster if the points are hard-coded as constant values, so they're cached directly by the CPU. I didn't bother with that though, to keep things simple.

Added ability to use a serialized public key (hex string) as base key.

This is detected automatically, no need for any command line changes.

I'll add a pubKey option as a base point tomorrow, but a warning will be given. Adding the P@Inf / doubling check inside the batch addition (X1 == X2) would slow down the processing slightly.

The math is already in EC space, There's no reason to provide G itself, it's a constant already. Using some other "step" point automatically means skipping keys. I think maybe you confuse this with the "number of steps" argument, which is just a factor for how many batches are computed per launch, by each thread. In my performance tests, a higher steps count increases the speed slightly, but uses more memory. Optimal values depend on specific hardware.

What's your use case for the lib?

Pretty easy to use a provided public key as the base point. But it would then be impossible to validate that the requested range doesn't include the point at infinity (unless the user is 100% certain that the public key's scalar is somewhere below N - rangeSize).

Not sure on why you'd need a step different then G. The range won't be covered. I assume you're referring to using something like (2G, 4G, 6G, ...) as delta steps, right?

Yaw!

I built a C library / demo app that demonstrates how libsecp256k1 can be used to do really fast batch addition and scan a given range from start to finish.

The resulted affine points can be streamed and consumed via callbacks, or this can be simply used as a crude measurement instrument to check your CPU's performance.

https://github.com/kTimesG/PointsBuilder

How it works?

- give it a range start, a size, and a number of threads to use. The rest is magic!

Only two EC point multiplications are only ever needed. For example, if you need to fully generate all the first 1 billion points starting from some scalar k (only 64 bit for this demo), and do it on 64 threads, you only need two initial point multiplications!

The code computes a constant points array, with G increments.

Batch addition is then handled directly using secp256k1 arithmetics.

The algorithm for my implementation of a batch addition is highly optimized - it is NOT the usual algorithm you might have seen elsewhere.

The goal of this demo is to show that it can run really, really FAST - in my tests, it's at least two times faster than the usual suspects that you may find in other projects, especially the ones in almost all VanitySearch projects and their clones.

The demo also allows saving the X coordinates into a database - this is not the goal of the code though.

You can run simple benchmarks by not specifying a database for storing results (because actually storing the results is several hundreds times slower than computing them in RAM).

Important note (forgot to add it in the GitHub README): the range start needs to be above 1024 (because otherwise the results will be incorrect - point doubling is assumed to never happen in the batch adder logic).

Note: this thread is self-moderated. Please no BS / AI / non-sense, except things that are related to this library.