Is this the new thread?

>>1739

Ok, I see, so for our na row, d and a will be (n-1)a more.

I don't know if I missed this earlier, and you guys already have it all figured out, but this is I think exactly what VQC meant here:

>Tomorrow I will show the way in which na and (n-1)a relationships between a[t] and d[t] in row 1 cells (e,1)

Have you been looking at these relationships in the a x b row too?

>>1740

Glad I could help, although this is all still very unclear for me.

I've found hundreds of relationships and interesting things over the last week, but none of them have been useful at all. I just keep redefining the problem.

>>1745

>Even went up to c^4 to see if there were any patterns at higher numbers.

Lol, I did the same.

Couple more clarifications:

> f = 2d + 1 - e

>>1744

>f is more important than you think. Take a look at (f, 1).

Isn't this formula around the wrong way? Wouldn't this give you -f?

I'm sure we said f = e - (2d+1)

If you keep performing that movement, eventually you can get back to the 1 row (or 0 row) as well but on the negative side.

Have you had a look at these relationships too?

>>1751

>In the original vqc, I used f = 2d+1-e as the negative -e coord.

Gotcha. Makes sense. Sorry I missed that bit.

>>1795

If you guys need to generate any more keys to test with here's how:

openssl genrsa -out ./test.key 128

openssl rsa -text -noout < test.key

The "modulus" field is the C to factor, prime1 and prime2 will be A & B.

Congrats CollegeAnon!!!

Show us that algorithm!

>>1794

Oops, I didnt notice the 1xC…

CA…

>>1798

C will be hex encoded.

and the "128" can be changed to any number and represents the length of C in binary.

Typical keys are 2048 bits.

>>1803

Ok, well, lets hope so ;)

If you need large semi-prime numbers to factor that we know the answer to, I can generate many for you.

>>1806

There's always that way too, but at least with using openssl you have control over bit size.

>>1816

Agreed, funny, but lets support each other too.

Wanna share your progress CA?

Or your code, maybe we can help.

>>1822

>Except he didn't put out a solution.

You're feeling a little feisty tonight anon? ;)

>>1825

I like your thinking PMA.

I'm trying to work on something now actually.

It seems that the x+n for 1xc and x+n for axb share factors.

So I've been following this stupid idea, not sure if it'll amount to anything, but I'm thinking that x+n is about half of c at the 1xc record.

And we know that the axb little square shares factors with the x+n, so why don't we recursively try to factor x+n.

Like I said, x+n for 1xc is about half of c, so that would suffice for our log n runtime.

Where I'm stuck is post finding our factors.

So recursively run down the stack, you eventually get to some prime number… then what?

>>1830

Oh, and if x+n doesn't share factors, d+n does, one is always even, one is odd.

>>1832

Correct, assumed.

Ok, one more thing…

I think some of this overlaps with CA's work.

So you calculate f for our 1xc row, and don't stop there, just keep repeating that calculation.

Eventually you will get back to n = 0, and at that point, -e will always be a perfect square.

Repeat that process again but from axb, same deal.

No new info yet, and I get it, I'm just iterating. But here's the thing…

If you log as you iterate from the 1xc record any time you hit a perfect square on the way to n=0, you'll only ever get 1 hit. And that hit will correlate to the same as the -e for axb.

I think this can actually be useful, I'm just trying to figure out how.

>>1835

At the point that you're at a perfect square, the n at that moment will be equal to 1xc.n - axb.n, which makes sense.

My approach now is to switch back to the algebra, write both equations and solve simultaneously.

The occurrence of the perfect squares is clearly parabolic and easy to calculate. The other is something I dont know the right word for. It not linear, its not exactly log (or exp if you go the other way), but similar to it. Math is my weakest part though.

Honestly, I think CA was trying to say a lot of these same thoughts back in RSA #6. I would not be surprised if he really was close to a solution.

>>1838

Here's my code (sorry for js, but pretty readable):

var newE = c1.e;

var newD = c1.d;

var newN = c1.n;

var newX = c1.x;

for (var i = 1; i <= c1.n; i+=1) {

newE -= 2*newD + 1;

newD += 1;

newN -= 1;

newX = Math.sqrt(-newE);

if (Math.sqrt(-newE) % 1 == 0 && newN 0) {

console.log('hittttt newE', newE);

console.log(newE, newN, newD, newX);

}

}

>>1840

Also, I'm not claiming my equation for newX is correct, but I'm not using it anywhere important.

I actually already did this calculation once before on my whiteboard, but I ignored it and moved on.

But if we're calculating next e = e - (2*d +1)

And each time we increment d.

What is the equation at e without calculating the previous e.

This has to do with using Sigma n = n(n+1) / 2.

>>1845

Notice the -e in the function. You have to flip the sign.

>>1843

If you want to calculate the e variable for any point in that series, you can calculate it instead of iterating.

The calculation to jump 's' number of steps backwards towards n=0, for e is:

E = e - (s^2 + (3+4d)s)/2

I hate to add new variables, but s will be the difference in n values, so if you start at n = 61 and you want to get to n = 5, s = 61-5 = 56.

>>1861

Yep, I've cleaned it up a bit for you (again, ignore my x values down in the bottom part):

213 = 3 * 71

a,b {"c":213,"e":17,"n":23,"d":14,"x":11,"a":3,"b":71,"t":6}

1,c {"c":213,"e":17,"n":93,"d":14,"x":13,"a":1,"b":213,"t":7}

—–

a,b f {"c":213,"e":-12,"n":22,"d":15,"x":12,"a":3,"b":71,"t":7}

1,c f {"c":213,"e":-12,"n":92,"d":15,"x":14,"a":1,"b":213,"t":8}

—–

Repeating f calculation on 1xc:

{ e: -12, n: 92, d: 15, x: 3.4641016151377544 }

{ e: -43, n: 91, d: 16, x: 6.557438524302 }

{ e: -76, n: 90, d: 17, x: 8.717797887081348 }

{ e: -111, n: 89, d: 18, x: 10.535653752852738 }

{ e: -148, n: 88, d: 19, x: 12.165525060596439 }

{ e: -187, n: 87, d: 20, x: 13.674794331177344 }

{ e: -228, n: 86, d: 21, x: 15.0996688705415 }

{ e: -271, n: 85, d: 22, x: 16.46207763315433 }

{ e: -316, n: 84, d: 23, x: 17.776388834631177 }

{ e: -363, n: 83, d: 24, x: 19.05255888325765 }

{ e: -412, n: 82, d: 25, x: 20.29778313018444 }

{ e: -463, n: 81, d: 26, x: 21.517434791350013 }

{ e: -516, n: 80, d: 27, x: 22.715633383201094 }

{ e: -571, n: 79, d: 28, x: 23.895606290697042 }

{ e: -628, n: 78, d: 29, x: 25.059928172283335 }

{ e: -687, n: 77, d: 30, x: 26.210684844162312 }

{ e: -748, n: 76, d: 31, x: 27.349588662354687 }

{ e: -811, n: 75, d: 32, x: 28.478061731796284 }

{ e: -876, n: 74, d: 33, x: 29.597297173897484 }

{ e: -943, n: 73, d: 34, x: 30.708305065568176 }

{ e: -1012, n: 72, d: 35, x: 31.811947441173732 }

{ e: -1083, n: 71, d: 36, x: 32.90896534380867 }

hittttt newE -1156

{ e: -1156, n: 70, d: 37, x: 34 }

{ e: -1231, n: 69, d: 38, x: 35.08560958569767 }

{ e: -1308, n: 68, d: 39, x: 36.16628264005025 }

{ e: -1387, n: 67, d: 40, x: 37.242448899072144 }

{ e: -1468, n: 66, d: 41, x: 38.31448812133603 }

{ e: -1551, n: 65, d: 42, x: 39.382737335030434 }

{ e: -1636, n: 64, d: 43, x: 40.44749683231337 }

{ e: -1723, n: 63, d: 44, x: 41.50903516103452 }

[[[ truncated a bunch of nonsense rows because "body too long" ]]]

{ e: -8436, n: 14, d: 93, x: 91.84770002564028 }

{ e: -8623, n: 13, d: 94, x: 92.86010984270911 }

{ e: -8812, n: 12, d: 95, x: 93.87225362161068 }

{ e: -9003, n: 11, d: 96, x: 94.88413987595608 }

{ e: -9196, n: 10, d: 97, x: 95.89577675789482 }

{ e: -9391, n: 9, d: 98, x: 96.90717207719973 }

{ e: -9588, n: 8, d: 99, x: 97.91833331914918 }

{ e: -9787, n: 7, d: 100, x: 98.92926766129425 }

{ e: -9988, n: 6, d: 101, x: 99.93998198919189 }

{ e: -10191, n: 5, d: 102, x: 100.9504829111778 }

{ e: -10396, n: 4, d: 103, x: 101.96077677224709 }

{ e: -10603, n: 3, d: 104, x: 102.97086966710536 }

{ e: -10812, n: 2, d: 105, x: 103.98076745244767 }

{ e: -11023, n: 1, d: 106, x: 104.99047575851822 }

{ e: -11236, n: 0, d: 107, x: 106 }

Repeating f calculation on axb:

{ e: -12, n: 22, d: 15, x: 3.4641016151377544 }

{ e: -43, n: 21, d: 16, x: 6.557438524302 }

{ e: -76, n: 20, d: 17, x: 8.717797887081348 }

{ e: -111, n: 19, d: 18, x: 10.535653752852738 }

{ e: -148, n: 18, d: 19, x: 12.165525060596439 }

{ e: -187, n: 17, d: 20, x: 13.674794331177344 }

{ e: -228, n: 16, d: 21, x: 15.0996688705415 }

{ e: -271, n: 15, d: 22, x: 16.46207763315433 }

{ e: -316, n: 14, d: 23, x: 17.776388834631177 }

{ e: -363, n: 13, d: 24, x: 19.05255888325765 }

{ e: -412, n: 12, d: 25, x: 20.29778313018444 }

{ e: -463, n: 11, d: 26, x: 21.517434791350013 }

{ e: -516, n: 10, d: 27, x: 22.715633383201094 }

{ e: -571, n: 9, d: 28, x: 23.895606290697042 }

{ e: -628, n: 8, d: 29, x: 25.059928172283335 }

{ e: -687, n: 7, d: 30, x: 26.210684844162312 }

{ e: -748, n: 6, d: 31, x: 27.349588662354687 }

{ e: -811, n: 5, d: 32, x: 28.478061731796284 }

{ e: -876, n: 4, d: 33, x: 29.597297173897484 }

{ e: -943, n: 3, d: 34, x: 30.708305065568176 }

{ e: -1012, n: 2, d: 35, x: 31.811947441173732 }

{ e: -1083, n: 1, d: 36, x: 32.90896534380867 }

{ e: -1156, n: 0, d: 37, x: 34 }

>>1869

Yep, and it makes sense algebraically too. I dont know if it helps us at all.

>>1871

Yep, agreed.

>>1882

I can access a 3d printer and would be very interested in sonoluminescence too.

What sort of materials are we talking?

>>1896

I understand what you mean with n and (n-1) and I agree.

>>1899

As to how to go backwards, it seems that you're correct, but there's plenty of primes in the list of a's and b's in (e, 1).

It looks like a lot of the a's are divisible by the first element a or b in the set? Or a prime.

>>1902

Ok PMA, here's something…

We know our original d.

And we know that there are 2 elements in (e, 1) that correspond to the na transforms you've described - one for 1xc that we know, and one for axb that we don't.

So lets describe our problem as finding the matching records in (e,1)…

We know that there's going to be a value for d in that list, that once we minus our original d, will be (n-1)a.

And that same element will have an a value of na.

So yes, we have to factor, but it can get a little easier because we know that n and n-1 are 1 apart!

Ok, I'm going to try to code some stuff to check, but this is really exciting.

To clarify, if two numbers are na and (n-1)a they are a apart… easy to minus one from the other and check if a factor, if not, keep going…

>>1908

How's 20 digit?

prime1: 17919528693253856099

prime2: 14339277256319437853

>>1918

You can get back only if you have a d that you're trying to get to, which we do, so I'll address that case, and i'll call it orig_d.

the dest_a = a - n - orig_d

the dest_n = a/dest_a

the dest_d = orig_d

>>1919

I'm not following MA, sorry.

>>1926

Try this one: 223916479610897

I'm not saying this to brag but I've been factoring 35 digit numbers in sub 10 seconds for days now, maybe weeks.

I say this because there's so much humble bragging going on in this thread and I'm so tired of it.

>>1893

This thread said it best.

Get humble.

Sorry for my outburst.

>>1935

Precisely, I've done it, CA did it, I'm pretty sure PMA has chased some tails.

And its totally fine. Its just the attitude. It makes this a less enjoyable community in my opinion.

>>1937

I believe using a traditional sieve (m or gf) would be faster still at this stage.

My solution does not scale, hence why I've been hesitant to post it. I optimize it and improve it, but its still no way log n.

My measurements in time though are strictly using the grid, and minimizing work.

I saw a video on Andrew Wiles discussing the 3 approaches to most mathematical problems (specifically number theory):

• geometrically

• algebraically

• analytically

I believe that using your eyes to view the grid and draw inferences and truths constitutes basic analytics.

Certainly I've been drawing a lot of geometry, as maybe you've seen my whiteboard pics.

And finally algebraically I've been trying to do the same on the whiteboard and code.

I think its a good mental approach to try to interpret all 3 and use all 3 approaches when solving this.

>>1940

I sincerely hope you crack it.

Sorry again, it wasn't meant as a personal thing.

>>1939

>>1941

There's several youtube videos that I've found that help me understand more of the scale. Mostly long lectures on ECC. I never studied math as a major, so I'm lost after 30 mins. But here's some youtube goodies:

• First, some history on FLT: youtube.com /watch?v=nUN4NDVIfVI

This is a numberphile video with Ken Ribet who provided a crucial element to the proof of FLT

• Then meet the man himself, Andrew Wiles, this is the interview where he talks about approaches to how to approach solving something like FLT: youtube.com /watch?v=cWKAzX5U85Q

• Really good elliptic curve description, has lots of our good old variables and relationships in it: youtube.com /watch?v=6eZQu120A80

• FLT explained by G. Frey: youtube.com /watch?v=UHvHW6HBtxI

>>2016

Yep, this is the relationship I was talking about yesterday.

PMA have you produced any of the images that VQC spoke about.

Visually you can see lines diagonally down to the right from every perfect square.

These lines cross the e=0 axis at the same frequency as the growth in squares (same sized gaps).

I think this is how we're supposed to figure out which other squares it hits on the way back from 1xc by using where it crosses e=0.