Initially deteterming the potential digits of a number N, at a given magnitude M(i), M(i+1), M(i+2), required about 10,000,000 iterations per digit group. I got that down to 2000 iterations, producing 200 candidates per group, about 1/5th the bitlength of the prior problems key size. So a key with factors that were say 650 digits long, rather than have to guess the digits from 0-999 for each 3 digit group, you had no more than 200 results to try, effectively reducing your search space from (999216) to 200216.
A 9 digit number can be factored in roughly.. (999^3)/(200^3) ~= 125 times less iterations.
A twelve digit number? 622 times faster.
A sixty four digit number? 798300146800470 times faster.
Etc.
That was good of course, but for very large bit lengths, even this is still impractical.
I realized if we just start with the 200 pairs of potential digits for the first two digits of the factors of n=p*q, then
we could string combinations of the range 0-9 in front of them, or at the highest magnitude, convert them back to integers,
multiply them together, and then once again match them against the digits of n.
False pairs in the initial set will fail to produce more digits of n at the same density as the true pair.
If our three digit pairs produce a product that matches 3 or more digits of n, that becomes a three-digit result pair, describing
one or more potential sets of digits for p and q.
We do this for all two digit pairs, to generate the set of potential 3digit pairs.
Finally, the optimization:
If none match we kill or filter out the 2digit parent pair.
Likewise the 3digit parent pair, and 4digit parent pair, on down the line, pruning branches.
The result should be a very minimal, and semi-linear search space that is much faster than the prior method.
I'm implementing it tonight.
There doesn't seem to be anything here yet