PointsBuilder - fast CPU range points generator

[kTimesG]

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’d like to be able to generate public keys even when the starting private key isn’t known, like in 32BTC puzzle

Not sure what you mean. All the 32BTC puzzles have a known starting private key. Using a pubKey as base key sounds useful for when you'd like to generate vanity addresses relative to an unknown private key (e.g. as a service).

[shinji366]

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)?

[kTimesG]

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.

[shinji366]

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?

[kTimesG]

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?

All the verifications and setup assumes a step size of G, so in order to change the step, it needs to be factored in everywhere where the step is assumed to be equal to 1:

- first constant point: step * (2 * num_const - 1)
- constant points from 1 to N - 1 start from step*G, increase by step*G
- validations for user input need to be updated as well (invalid ranges, etc.) - sounds like this is your error
- maximum range size can no longer be 64-bits (reduces by size)

For 512 constant points with a "size" of 1, the range cannot start at key 512, because a pivot starts at key 1023 (= 512 + (NUM_CONST - 1), and it will fail to compute 1023G + (2*NUM - 1)G.

If the step size is 2, then by the same logic C[0] = 2*1023 = 2046. And the pivot starts at (start + step*(NUM_CONST - 1)). Solving for this equation (pivot == C[0]) means that now we have to ban the range from starting at 2046 - 2*511 = base key 1024. Or more simply, NUM_CONST * size.