Quote from: kTimesG on June 21, 2025, 05:26:46 PM

Quote from: shinji366 on June 21, 2025, 04:28:50 PM

Quote from: kTimesG on May 19, 2025, 07:20:31 PM

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

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

Thanks again! I finally had some time to test this and works great!

Is it possible to adapt this code to generate keys separated by value other than 1(G)? Meaning keep the speed but instead of calculating G,2G,3G,4G do G,3G,5G or any other size? Could this be done to accept any value for step or would you need to decide on the step before changing the code (math)?

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.

I tried to adapt the code to accept variable step but I seem to have trouble at window edges. Works fine until last value 512 (which is always 511+1G instead of 511+step*g) in first set, then skipped completely next (1024 entry is given 1025 value) then plus 1 then skipped etc. Do you know why this is happening?