>>5149

Ok, so if we find u, we can solve (x+n). How does n0 work into this? For smaller examples we can iterate by 1. Then, once f is big enough to divide (f-2)/8 we can iterate by n0. Then when we’re dealing with RSA sized numbers we do (f-2)/40 and iterate by n0. What are the problems you’re currently having with the iteration process for larger numbers? It seems like we have a good working process for smaller numbers. The key is tying the verification calc to the formula ((n0 * n0 - 1) + 2d(n0 - 1) + 2d +1 - e).

I think this is what VQC was getting at. n0^2 and 2d(n-1) combine to form the (x+n) square. I could be stating the obvious, but this is news to me.

>((n0 * n0 - 1) + 2d(n0 - 1) + 2d +1 - e)

>>5151

Hmm. Understood. How can we create a method to know if we’ve “flown by” the correct (x+n), and then backtrack with smaller values until we find the solution?

>>5153

Gotcha. This is what I was also getting at about using the quadratics to verify by solving for n using the (x+n) estimation.

>>5155

PMA, you just made a triangle joke! And you made your first shitpost last week. Nice!

Hey lads! Still working on tying the n0 iterations together with the quadratics to verify when we reach the correct n value. Just checking in.

>>5204

>>5206

Hello PMA! Great work as usual, thanks man. I'm a bit stuck where you are on the iterative approach.

>It seems to me that there are 2 ways to iteratively find a solution. Both have been problematic.

Yup.

>The first is to start at a sufficiently small triangle base and iterate in chunks of (f-2)/40 towards the c (x+n)(x+n) square. Using the remainder 2d(n-1) = 0 along the way to determine if an n match has been found.

Yup.

>The second, that I pursued in the previous thread, is to iterate towards the "capstone square" which always lies somewhere between the prime and c small squares. The problem here was determining if a solution was found.

See pic attached, I got 0 at the correct (x+n) value. Also, very interesting to note that it was n0[99] - 4 = 7227 - 4 = 7223. What was the part about the mod being 4? Found these related crumbs:

>>4332

>>4337

>>4342

Seems like the mod for each Tu is 4 in VQC's example? Thoughts, Anons? In my sheet I got n0[99] - 4 = 7223 = correct (x+n) value. However, mod for my example is 28.

I'm working through all of RSA#10 re-reading VQC's crumbs. Every time I read them I understand more.