Anyone else noticed that (x+n)^2=f in (e,1)?
I think once n 1, you can’t rely on the parity anymore. n is any factor in (e,1). And you x’s will either be odd or even. So you’re going to get mixed results as you go higher up the tree.
Not yet. This seems like the next fork in the decision tree, and we can certainly determine the parity of n, x+n, and d+n from e. Earlier VQC mistyped c for e. Perhaps this e mod 4 rule applies to d+n?
I wouldn’t presume to say that. So I’m confused.
Notwithstanding, seems pretty obvious that we’re looking for a triangle formula the for small square when odd. And there is some way the tree gives that to us.
You would also think this 1+8T formula applies to smaller trees. But with really small odd x+n values you’re getting into some small fractions.
Yeah, I remember the bit about pi as well. That and the grid structure really got me thinking.
I believe the n0 calculation is an approximation to get the ball rolling.
Just the first step in the process that I believe will integrate with the tree, and then ultimately the grid.
VQC is breaking this all into small steps for us to fully understand the process.
This might be overkill with the whole parity thing, but…
Attached is a pic of all Rsa values sorted by c with "predicted" parities based on e value only for n, x, x+n and d+n.
I've tested this code against all my test cases based on c and ab records and it seems to work fine.
Would appreciate a double check.
pastebin.com/1hx1R0px
Great walkthrough.
n0 = 1
(f-2) mod 8 = 4 (the left over blue squares from VQC images)
+1 from the origin 8Tu + 1
total: 6
Is this the n we are looking for?
Maybe for smaller numbers that don't fit GDC, this single iteration of GetNFromOddTriangleBase is sufficient?
Few samples attached where n is even. These tests incorporate the gcd and f-2 resolving of n.
There are some cases where (f-2) finds a matching n. These tests do not increase 8 by any factor.
I think we have a basic understanding of the initial concept (really important!!), and we definitely need to iterate further (which VQC previously mentioned).
So how do we fill the gap to find the multiples of 2d?
Ran a couple more parity and small square triangle tests for even n.
Rsa200 - Rsa768 pic related.
Confirmed that parity is same for c and prime solution records. (I think we knew this already).
Looks like this formula works for both odd and even (x+n) when n is even? weird?
Also uploaded static class with all Rsa numbers.
pastebin.com/XYFpsDWE
Fyi, Rsa704 and Rsa220 had the a and b values reversed from our perspective on the source wikipedia page.
en.wikipedia.org/wiki/RSA_numbers
The x+n value we are looking for here is 21.
VQC hints talk about filling the remaining portions of the triangle with n0 squared and 2d.
For n0=4 in your example:
n0*n0 + n0 + 1 = x+n
4*4 + 4 + 1 = 21.
The 2d value would be too large.
So where does this logic come from? Does the factor tree tell us anything?
:-)
Pic attached are a few examples of my current understanding of this process.
Step 1: Calculate n0 using a triangle base from (f-2) div 8. (Replaced div 40 with div 8 for smaller numbers).
Step 2: Calculate the remainder 2dnm1 (gap) using the same triangle base and the n0 result from step 1.
Thanks for reposting with annotations.
I've tried a number of different factors * 8 when computing n0. For smaller numbers, it does make a difference in the n0 return value.
If the important thing about the base is having a number between n and x+n, then there has to be something in the original c, d, e or f values that tells us what to use.
VQC did say it was arbitrary. >>4340
But then why go into such detail about these blue lines?
Sorry VA, no conclusions here.
the comment from VQC in >>4343
>We will add a method to calculate what would be missing from the triangles if we could only fill them with n0 squared and multiples of 2d.
I believe is being handled by the call to Get_Remainder_2dnm1. It takes the n0 and d values as parameters, and internally uses 2d and nn.
I think we are now looking for this part of the puzzle which is the return result of Get_Remainder_2dnm1:
>That gap will allow us to use more geometry of triangular numbers to establish what multiple of 2d could be added to make our eight triangles.
MM - The "gap" that I calculated for c=6107 is 140. Breakdown in >>4633
Perhaps there is some way that number could be reflected in your diagrams. It is close to another triangle number T(16). And T(16)/8 = 17.
And here is the factor tree for c=6107:
-
6107 (c)
| + 78 (d)
| | + 39 (/2)
| | | + 6 (d)
| | | | + 3 (/2)
| | | | | + 1 (d)
| | | | | + 2 (e)
| | | | | | + 1 (/2)
| | | + 3 (e)
| | | | + 1 (d)
| | | | + 2 (e)
| | | | | + 1 (/2)
| + 23 (e)
| | + 4 (d)
| | | + 2 (/2)
| | | | + 1 (/2)
| | + 7 (e)
| | | + 2 (d)
| | | | + 1 (/2)
| | | + 3 (e)
| | | | + 1 (d)
| | | | + 2 (e)
| | | | | + 1 (/2)
>I'm really hoping we aren't in this proto middle-land stage too long!
Agreed. Well, at least I can now generate small number records in js.
Very interesting to show each iteration geometrically. I was thinking more along the lines of the final prime solution, with the small square only partially filled in. And the "gap" result somehow highlighted. (No idea what this would look like.)
>After all that, for those that are interested, we'll then use the virtual quantum computer patterns in the original grid to short cut all this.
Interested? Of course!!!
Also would like to learn how the factor tree plays into this.
It looks like from your diagram >>4678 that the answer can be calculated.
Thanks again for sharing this knowledge.
Great pictures Isee.
Pic attached is for c=39, showing (x+n)(x+n) for the prime solution in the middle, and "growing" the small square into the starting c position.
Just a thought to share while looking for differences.
2d(n-1)-f ?
I don't think the "capstone" starting position in VQC's image is properly labeled as (n-1).
In the c=115 picture, the large red square is 31x31. The bottom of the capstone would be (31/2 = 15.5) and not 48-1. I believe this 31x31 square divided into 8, are the "sub-triangles" that VQC was referencing.
From these diagrams, I think there is a relatively straight forward way to calculate our solution n:
solution n = (x+n)(x+n) - "dark purple bases of triangle" - 2d(n-1) - f.
What's left behind after this calculation is the light colored purple n in the middle of the inner solution square.
Because we don't know the size of the 31x31 square in the middle, the n0 formulas and the (f-2) mod 8 calculations are used to iterate towards the base of the capstone. Testing along the way if we have solved the problem.
Following is the math breakdown for what I was referencing above:
5x23=115
c = (15,48,5) = {15:48:10:9:1:115} = 115; f=6; (x+n)=57
p = (15,4,3) = {15:4:10:5:5:23} = 115; f=6; (x+n)=9
For the c record, the revelant calculations are:
(x+n)(x+n) = 57x57 = 3249
(nn-1) = 48x48 - 1 = 2303
2d(n-1) = 2x10x(48-1) = 940
f = 6
Verify:
3249 = 2303 + 940 + 6
For the p record, the relevant calculations are:
(x+n)(x+n) = 9x9 = 81
(nn-1) = 4x4 - 1 = 15
2d(n-1) = 2x10x(4-1) = 60
f = 6
Verify:
81 = 15 + 60 + 6
This works regardless of how f is divided in the squares. The important piece is that f is equal in both records.
Assuming we can calculate the red square (i.e. the n-1 capstone in VQC's post)
31x31 red square = 961
The nn-1 portion in the dark purple area is the triangle base and can be calculated as:
3249 - 961 = 2288
Once we have the triangle base, there are 2 ways to solve this from the original c record:
solution 1:
(x+n)(x+n) - (nn-1 triangle base) - 2d(n-1) - f = (nn-1) from solution small square
3249 - 2288 - 940 - 6 = 15
solution 2:
(nn-1) - (nn-1 triangle base) = (nn-1) from solution small square
2303 - 2288 = 15
To get our solution n:
nn-1 = 15
nn = 16
n = 4
This theory hasn't been tested on many records as I'm still not sure how to programmatically determine the dark purple triangle base. I do believe we have all the code pieces required, however.
Would appreciate someone else double checking this.
That’s a different f. That 2d+1 was a transform into the negative e space. It created a mirrored record in the negative half of the grid.
The f we’re talking about here is the distance to the next squarefor each record.
Guys. The math checks out for odd_e, even_d, odd_x_plus_n.
Attached are test cases for c=115, 259, 6107, and 7463. I have tested all known matching Rsa solutions against these formulas, and they work as well.
The top part of the test cases should be self explanatory.
The bottom portion is the remaining work to be done.
Currently, I am iterating from 1 to x+n, and executing the Get_n_from_odd_triangle_base, Get_Remainder_2dnm1, and Get_XPN_from_f methods posted earlier.
If you add Remainder_2dnm1 to Get_XPN_from_f, you always get square. See the total, sqrt(total), and diff columns.
One of those squares represents the capstone square that will solve this problem.
While iterating those squares, I have found the following:
1) The n from the starting c and prime solution records always appear in the n0 column.
2) Once the remainder 2d(n-1) result is greater than or equal to c, it will always return c.
3) The "capstone" square that we are looking for may or may not appear.
3a) in c=115, it shows up directly via iteration.
3b) in the other test cases, we get records that are +/- 1 away from the capstone. See c=259 for capstone +1 match, and capstone -1 match.
3c) So to find the capstone square, we need to check +1 and -1 of the sqrt(total).
I believe this is why VQC showed the f div 40 + 2 through f div 40 - 2 triangle side >>4344.
The 5 factor in the denominator may be arbitrary, but when searching for a solution, we need to check +2 through -2 records to find the capstone match.
>If doubling the width of the chunks of (f-2) didn't give us a solution, the number c would be prime, the worst case (doubling the width of (f-2) chunks very quickly determines this as the number of times it doubles is logarithmic in the length of (f-2)).
This is the remaining piece that will replace iterating with larger jumps.
Thank you!
Just to confirm previous posts, the following solutions work for all numbers:
solution 1:
(x+n)(x+n) - (nn-1 triangle base) - 2d(n-1) - f = (nn-1) from solution small square
solution 2:
(nn-1) - (nn-1 triangle base) = (nn-1) from solution small square
Finding the base of each triangle capstone needed to calculate the (nn-1 triangle base) at this point seems to require iteration - until VQC drops hints about more effectively using the grid.
The (nn-1 triangle base) is the dark purple area in the image at >>4758.
The starting position for an iterative search can be set as:
(2d(n-1) + f)/8
This represents a triangle within the red square including the blue f portion. The only piece missing is the n we are looking for.
Attached test cases for c=115, 259, 6107, and 7463, are an attempt to move closer to an understanding of the iterations required. And to verify that the starting triangle base is less than or equal to an estimated capstone triangle base.
The "triangle base" entries are calculated as inverse triangles from the triangle area. I believe baker posted this formula previously:
(Sqrt( 8 * area + 1 ) - 1) / 2
From the (2d(n-1) + f)/8 triangle starting position, we can iterate (f-2) div 8 or (f-2) div 40 steps, checking for +/- 5 proximate values each way for any possible solution. Although I'm not sure how many proximate values need to be checked. Could be +/- 10, 50, 100?
The "estimated iterations" value is calculated as:
(capstone_triangle_base - starting_triangle_base) / BigInteger.Max( (f-2) / 8, 1 ) + 1;
Follow up to the starting position from >>4815.
I confused the "triangle_base" with x+n inputs.
I believe the correct parameters are as follows:
BigInteger n0 = Get_n_from_odd_triangle_base( (x+n)/2, c, d );
BigInteger r2dnm1 = Get_Remainder_2dnm1( (x+n-1)/2, d, n0, f );
BigInteger XPN_from_f = Get_XPN_from_f( n0, d, f )
Attached are examples for c=115, 6107, and 14904371.
I am estimated an (x+n) starting position to use in the above formulas, and iterating by 2 for only odd values of (x+n).
Starting x+n = 2 * (GetInverseTriangle( 2d(n-1)+f ) / 8 ) + 1;
In some cases, this puts us exactly at the correct capstone record.
The "cap diff" column represents the difference in the target capstone area and the iterated total value. I'm iterating until that value becomes negative.
This starting formula allows pretty big jumps and relatively few iterations, even without adding in the (f-2) div 40 chunks - which will be required to handle RSA length numbers.
The current problem is accounting for the difference between the "target capstone area" and the (x+n) with the last positive "cap diff".
How do we know we've hit the correct capstone?
from >>>/qresearch/463046
I think relevant to our journey anons.
>be prepared to make some mistakes…True knowledge must be obtained the hard way…
Test cases for c=6107 iterations attached showing f-2 and x+n calculations, including a breakdown of the 2d(n-1) remainder.
Tests are run using different base factors of (8, 16, 24, 32, 40). For each iteration, also testing +/- proximate range of 2.
Best result so far is 21 calculations, using an f-2 div factor of 16. Base factor of 24 fails to find a record.
Example for c=c9874400051 attached, with different base factors, proximate range searches, and relevant records only being shown.
This example takes 1493 calculations to solve.
I'm not quite sure what improvement this algorithm brings to the table. We could just as easily increment x+n guesses by 2 and arrive at a similar solution in 909 calculations.
Definitely not seeing something.
Perhaps there is a way to jump further ahead, and then iterate at a more granular level.
Perhaps this is how the factor tree comes into play?
Really big jumps at the top of the tree, and then smaller and smaller jumps as we get closer to the solution.
And then finally the +/- proximate searches.
Correct. Stop on remainder 2d(n-1) = 0, and "x+n diff" as a validation.
I agree on the progress even though we don't have a solution yet. There has been so much to absorb in just this thread alone.
Agreed MA. This is VQC's deal. Happy to be along for the ride.
>I don't think we have the additional function yet?
I think this was the Get_Remainder_2dnm1 used in our current tests.
Trying your idea out. See attached c=6107 variations including a c estimate and c diff columns.
c est is calculated as (d+n0)(d+n0) - (x+n)(x+n), where the n0 and (x+n) values are from the current iteration.
c diff is the difference between c est and the original c value.
In the failed test result, notice that the c diff never goes negative. I believe this is because the x+n value is always increasing.
Am I missing something?
Also notice the c diff value is the same as the rm 2d(n-1) column. So I think this is already considered in the Get_Remainder_2dnm1 formula.
>It's working?!
In the sense that it can "sometimes" find the correct (x+n), yes.
For small values of n, it works pretty well, even on relatively large numbers.
For larger values of n, it takes a bit longer. And will sometimes skip over a matching (x+n) even though the correct n has been found.
Leads me to think that a success should check for more than just remainder 2d(n-1) == 0 to add a bit of tolerance. Unless we can iron down the estimation formula a bit better.
It's also too dependent on the base factor - div 8, 40, 400, 32, 64, 256 all work but for different test cases.
Anyone wants to play along, the f-2 estimation code snippet is attached.
Moving quickly isn't really the problem. We are missing something fundamental in how the (x+n)(x+n) is estimated relative to the 2d(n-1) remainder and (f-2) div/mod.
These discrepancies get amplified as the numbers get larger.
For example, not quite sure how this crumb factors in.
>We then know that if the base of f/40 is too small, then the number of 2d to add must have the same left over on the last d to create the final base of each triangle. THIS is key.
Back to some math to try and understand this estimation properly. Trying to incorporate >>4337.
Given:
nn-1 + 2d(n-1) + f = 1 + 8T(u) = (x+n)(x+n)
In terms of 8T(u):
nn + 2d(n-1) + f - 2 = 8T(u)
In terms of T(u):
(nn + 2d(n-1))/8 + (f-2)/8 = T(u)
In terms of T(u) as integers:
(nn + 2d(n-1))/8 + (mod 8) + (f-2)/8 + (mod 8) = T(u)
In terms of 1/5 T(u):
(nn + 2d(n-1))/40 + (f-2)/40 = T(u)/5
In terms of 1/5 T(u) as integers:
(nn + 2d(n-1))/40 + (mod 40) + (f-2)/40 + (mod 40) = T(u)/5 + (mod 5)
Where the (mod) value is the remainder from the closest left division expression.
Thoughts?
Pic attached for c=6107 and Rsa 100, showing the breakdown between nn, 2d(n-1), (f-2), and their respective mod results.
Included is an analysis of the various triangle formulas 8T(u), T(u), and T(u)/5 - which equates to div 40. T(u) represents the area for one of the 8 triangles that makes up the odd x+n square.
This was an attempt to explore the relationship between the mod values and how they affect the estimation required for an iterative solution.
In these pictures, u represents the triangle base - the blue bar in VQC's images.
The reason the iterative solutions are failing so far is because of the u % ((f-2)/40) result at the bottom. Finding something to quickly fill that gap is the problem.
Spreadsheets look good.
Have you given any thought to the relationship between the large square and the small square?
in >>4678
>We are creating a method that USES f as a guide to find how to construct the square.
Is there something in the large square that directs the use of f further into estimating 2d(n-1) or nn ???
Very interesting observation.
Attached diagrams are attempts to further understand the relationships between e, f, dd, nn-1, and 2d(n-1), the small and big squares, triangles, and how this might lead to an iterative solution.
These examples represent the prime solutions for c=115, c=259, c=287, and a partial view of c=6107.
The 2 light blue blocks from (f-2) can always be positioned one in the center and the other to fill the nn-1 square.
The (x+n)(x+n) square is bordered by e and some dd blocks represented in light grey. I was looking for a way to define a boundary for the small square that could be calculated.
Also notice how the light blue f squares can start directly after the green e squares. Together they sometimes match the x+n side or get pretty close.
In the c=6107 example, there are 2 lightly colored vertical lines that represent (f-2)/2 and (f-2)/2 + (e-1)/2.
This was an attempt to use the e and f relationship to find a better starting position for the (f-2) div 40 iterative search.
An estimated triangle base can be calculated as:
u = ((f-2)/2 + (e-1)/2) / 2
In some cases, this formula will find an exact match. In others, it can be used as a starting position for a quicker search.
Unfortunately, there are quite a number of cases where this completely misses the mark. RSA values and small values of n in particular.
Yes, I believe we estimate the base of one triangle, compute it's area, then the square, account for the 2d multiples and mods, and check for a match.
Still stuck on an iterative solution, but sharing some images with the hopes that someone else will have a better insight into this.
Attached are pictures for c=259 at various stages during the iteration process while determining n0.
Examples are for n0=2, n0=3, n0=4, and the final solution where n=6. Darker colored squares are the values after n0 has been determined.
The f-2 calculation on the right of each image shows the iteration step, f-2 div 40 and f-2 mod 40 results, and the triangle formula. Currently using just the iteration*(f-2) div 40 result as the triangle base. Not quite sure yet how the mod 40 factors in.
One thing that has become a bit clearer in doing this exercise is the meaning of the remainder 2d(n-1) calculation.
It's the difference between the 1+8T(u) formula and the nn-1 + 2d(n-1) + f formula for the small squares.
Also, just a guess that the "All your base are belong to us" comment somehow relates to the triangle base (u) in the small square formula.
I’m a bit slow!!!
Thanks, VA. I think we all have made that leap of faith.