Quote from: zahid888 on Today at 03:20:02 AM

One of my forks includes stride logic—I saw you mention somewhere that stride doesn’t work properly above 32-bit or something like that… Well, My stride version is unlimited and working flawlessly with zero issues.

The issue with unlimited stride values in this script stems from several limitations in how the code handles large numbers, particularly with the SetInt32() function and related arithmetic operations.

The SetInt32() function can only handle 32-bit signed integers (range: -2147483648 to 2147483647).

When you try to set values larger than this (e.g., stride = 1000000000000), it will overflow and produce incorrect results.

The script uses privateKey.Add(&step), where step is set via SetInt32().

This means the maximum reliable stride you can use is 2^31-1 (2147483647).

The script processes keys in batches of 512 (POINTS_BATCH_SIZE × 2).

The stride is multiplied by (fullBatchSize - 2) = 510, further limiting the effective stride.

To support larger strides, you would need to replace SetInt32() with a function that can handle bigger numbers (such as SetBase10() or SetBase16() for arbitrary precision).

However, SetBase10() or SetBase16() alone are not enough, you would also need:

A new batch processing engine
Stride-aware point precomputation
Non-linear batch assembly logic
Custom AVX2 memory gather operations
A new progress tracking system
Estimated development time: 14–20 weeks

Without these changes, the script might compile, but it would produce mathematically invalid results—which I have confirmed here in my posts.

And no, I’m not ashamed to admit when I’m wrong. Grin