/vqc/ - Virtual Quantum Computer

CodePost Guide

Because of the tendency for post links to disappear I will now be using Pastebin.

C#

BigInteger Square Root —— pastebin.com/rz1SdACZ

Generate Bitmap within original code —— pastebin.com/hMTtJF6E

More on generating a bitmap with the original code —— pastebin.com/JUdtehb4

Generate the large square for e and t —— pastebin.com/nbjs2kz4

Original VQC code —— pastebin.com/XFtcAcrz

How to run VQC code on Linux —— pastebin.com/6HnN7K5X

Unity Script —— pastebin.com/QgAXLQj3

Unity Script 2 —— pastebin.com/Y38nVWgT

Java

Create a Bitmap using the VQC Generator —— pastebin.com/Dgu9aP1h

VQCGenerator —— pastebin.com/VMRnkXFP

Traverse the VQC cells in real-time —— anonfile.com/W44cofd6b6/VQCGUI.7z

Traverse the VQC cells in real-time [V2] —— anonfile.com/TeH6q3d8bd/VQCGUI_v2.7z

NodeJS

BigInteger Library and Sqrt —— pastebin.com/y8AXtFFr

Python

College Anon's code (VERY USEFUL) —— pastebin.com/d8xZZnm0

Create the VQC —— pastebin.com/NZkjtnZL

3D VQC —— pastebin.com/vdf8SpYt

3D VQC (v2) —— pastebin.com/wZM5Thzu

Fractal cryptography —— pastebin.com/XuN4U7Dv

Generate cells for a (and more) —— pastebin.com/iAizgLFF

Generate any cell in (0,1) and (0,2) —— pastebin.com/gRTYpdMU

Generate genesis cell —— pastebin.com/GKzcCpMF

Generate positive AND negative genesis cells —— pastebin.com/9ixjRyxt

Get A and B from C and N example —— pastebin.com/s0SZ9BNF

VQC + t —— pastebin.com/Lgufk0db

Rust

Check if a number is prime —— huonw.github.io/primal/primal/fn.is_prime.html

Create Bitmap using the VQC Generator —— play.rust-lang.org/?gist=c2446efeec452fe14e1ddd0d237f4173&version=stable

Create Bitmap using the VQC Generator [V2] —— pastebin.com/zGSusyz5

Additional VQC code —— play.rust-lang.org/?gist=50def916ad48400bc5d638fbf119ae85&version=stable

Generate the VQC —— play.rust-lang.org/?gist=6b6beb372b6b931f1abd30642a35a80c&version=stable

Previous Threads

RSA #0, or the VQC thread —— archive.fo/XmD7P

RSA #1 —— archive.fo/RgVko

RSA #2 —— archive.fo/fyzAu

RSA #3 —— archive.fo/uEgOb

RSA #4 (not finished, but dead) —— archive.fo/eihrQ

RSA General (#5) —— >>7

RSA #6 —— >>848

Videos and Links

For those who are passionate about cryptography (or want to be).

Integer Factorization of any arbitrary integer — Part One

youtube.com/watch?v=9FeROMe0KBU

The RSA Encryption Algorithm (1 of 2: Computing an Example) (Very Simple)

youtube.com/watch?v=4zahvcJ9glg

Encryption and HUGE numbers - Numberphile

youtube.com/watch?v=M7kEpw1tn50

Public Key Cryptography: RSA Encryption Algorithm

youtube.com/watch?v=wXB-V_Keiu8

RSA-129 - Numberphile

youtube.com/watch?v=YQw124CtvO0

Elliptic Curve Cryptography Overview

youtube.com/watch?v=dCvB-mhkT0w

A (relatively easy to understand) primer on elliptic curve cryptography

arstechnica.com/information-technology/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/2/

Elliptic Curve Cryptography: a gentle introduction

andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/

Elliptic Curve Point Addition

youtube.com/watch?v=XmygBPb7DPM

Map of Chris (lel)

RSA #2

>>>/cbts/50228

>>>/cbts/53383

>>>/cbts/53432

>>>/cbts/53436

>>>/cbts/53466

>>>/cbts/53468

>>>/cbts/53469

>>>/cbts/53473

>>>/cbts/53475

>>>/cbts/53479

>>>/cbts/53481 *** importante

>>>/cbts/53482

>>>/cbts/53607

>>>/cbts/53609

>>>/cbts/53613

>>>/cbts/53615

>>>/cbts/53662

>>>/cbts/53668

>>>/cbts/53673

>>>/cbts/53678

>>>/cbts/53680

>>>/cbts/53681

>>>/cbts/53699

>>>/cbts/53770

>>>/cbts/58934

>>>/cbts/59055

>>>/cbts/65200

RSA #3

>>>/cbts/87168

>>>/cbts/87234

>>>/cbts/87300

>>>/cbts/87378

>>>/cbts/87414

RSA #4

>>>/cbts/98492

>>>/cbts/98560

>>>/cbts/107338

>>>/cbts/107342 rt >>>/cbts/107256

>>>/cbts/111903

>>>/cbts/111975 rt >>>/cbts/111942

>>>/cbts/111983

>>>/cbts/112148

>>>/cbts/112422

>>>/cbts/112425

>>>/cbts/112429 rt >>>/cbts/112172

RSA #5

>>11

>>12

>>17

>>18

>>19

>>20

>>21

>>23

>>24

>>25

>>26

>>27

>>28

>>29

>>30

>>31

>>32

>>33

>>495

>>699

>>709

>>710

RSA #6 (to date)

>>1099

>>1380

I just realized it let me post without a subject. Forgive me for that, we'll just call this the unnamed one eh?

>>1721

Thanks, I'll take a look.

>>1737

>>1739

Furthermore, it "closes the gap" between the f and small square formulas.

>>1572

Reposting again from VQC:

( f is what you add to c to make a square )

f = 2d + 1 - e

( x + n )( x + n ) = nn + 2d( n - 1 ) + f - 1

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.

>>1742

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

>>1743

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

Yes. I've got output for all the test cases we previously discussed with their na transforms, plus various increments of e.

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

>>1744

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

I have a feeling… Looking into right now!

>>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?

>>1745

The VQC is 3-dimensional, and making an a^3 * b^3 = c^3 cell would create cubes instead of squares.

Chris said you could draw a line of symmetry down the VQC and fold it onto itself. (f, 1) is how.

>>1746

I took the formula for the VQC code. So many "mirror" crumbs, and f is the mirror.

>>1721

This is actually very neat. I like this. How did you make this? I'd like to know how to add to it.

>>1747

So the (f,1,t) entries are interesting.

Example below.

145=5x29

a x b *=> (1,5,4) = {1:5:12:7:5:29} = 145; f = (2 * 12) + 1 - 1 = 24; (5*5) + 2 * 12 * (5 - 1) + 24 - 1 = 144; (x+n)^2=12x12=144;

a x b na => (1,1,4) = {1:1:32:7:25:41} = 1025; f = (2 * 32) + 1 - 1 = 64; (1*1) + 2 * 32 * (1 - 1) + 64 - 1 = 64; (x+n)^2=8x8=64;

a x b e=f => (24,1,4) = {24:1:36:6:30:44} = 1320; f = (2 * 36) + 1 - 24 = 49; (1*1) + 2 * 36 * (1 - 1) + 49 - 1 = 49; (x+n)^2=7x7=49

1 x c => (1,61,6) = {1:61:12:11:1:145} = 145; f = (2 * 12) + 1 - 1 = 24; (61*61) + 2 * 12 * (61 - 1) + 24 - 1 = 5184; (x+n)^2=72x72=5184;

1 x c na => (1,1,6) = {1:1:72:11:61:85} = 5185; f = (2 * 72) + 1 - 1 = 144; (1*1) + 2 * 72 * (1 - 1) + 144 - 1 = 144; (x+n)^2=12x12=144;

1 x c e=f => (24,1,6) = {24:1:72:10:62:84} = 5208; f = (2 * 72) + 1 - 24 = 121; (1*1) + 2 * 72 * (1 - 1) + 121 - 1 = 121; (x+n)^2=11x11=121

Similar to the na records, the e=f records satisfy the condition f = (x+n)^2.

Any more crumbs to share while I look for additional relationships?

>>1746

I don't know that we are talking about the same f. Someone else please clarify

The original F formula was used to create a record in the negative part of the grid. You are correct with "f = e - (2d+1)".

But VQC most certainly posted the other formulas:

from your pastebin

https:/ /pastebin.com/eHJTEwWY

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

>f = 2d+1-e (f is what you add to c to make a square)

>(x+n)(x+n) = nn + 2d(n-1) + f - 1

>>1751

Yeah, and I'm sorry I can't just provide the meat of it, I had a friend that worked through this but would not share all of it.

I'm not exactly sure if it's f or -f that shows this, but f shows you that the cells left of 0, e<0 are literally just a mirror of the cells on the right of 0, e>0.

>>1751

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

Gotcha. Makes sense. Sorry I missed that bit.

>>1752

Fair enough. Thanks.

The EZ Bake uses a lightbulb to operate.

Left y'all some snacks!

>>1749

>>1755

The secret ingredient is Topolanon!

https://hooktube.com/watch?v=-VckYVPjXTA

https://hooktube.com/watch?v=kWNHvIt9ryk

>>1758

;)

>>1759

>>1760

>>1761

Alright! We got some Victory Ponies over in Ez Bake Crematorium. Thanks Baker!

>>1750

All I did was go through each of the threads, copy and paste the relevant posts and separate them with a line of dashes. I didn't do any formatting (which is why some posts look different to others).

>>1755 we got some bitchin' batter to be throwin' in. doze 40watts are cookin' @1.21gigawatts!

>>1757 v.nice MA, or should we call you Claude!? The secret ingredient is LOVE damnit!

>>1761 pony up!

The quick links to EZ bake sure work nice for flow - we be syncin' anons!

>>1768

You do realize that if f = (x+n)^2

Then sqrt(c + f) - d = n?

>>1770

sorry, I'm not explaining myself very well.

there's an alternate formula that VQC gave us for (x+n)^2.

nn + 2d( n - 1 ) + f - 1

I'm checking to see if that formula equals f = 2d + 1 - e.

>>1770

sorry again. yes, I do realize.

I posted earlier that we may be able to solve this with just the (x+n) value.

Struggling to find any connection between any of these records.

>>1772

Yes, you can solve it if you're able to find (x+n).

>>1773

>Yes, you can solve it if you're able to find (x+n).

thanks! ;-)

>>1773

>>1774

Hey PMA! So are those old t equations going to work for small square? Was it:

even e: (2t)^2

Odd e: (2t-1)^2

I think that’s correct.

Also, do the transformations to row one work for other examples?

>>1775

Small square equations are good. If we can identify the (x+n) of the desired record, we have t and a direct link.

Not sure about the transformations for other examples.

>>1768

I've currently got a workflow set up to create na, f and "-" negative records.

Don't know if these are even the records that can potentially link to an answer.

>>1777

Why don't you hash the two primes of the first unsolved RSA number?

>>1777

Trips confirm.

>respond within 30 minutes

It's 1:41am in the UK right now. He'll be asleep.

>>1779

When should I set the limit? He said Trump told him to hold off but I also want to be the first to post it lmao

>>1780

First you should prove that you solved it. Are there are RSA-encrypted messages out there? You know, maybe someone's emails got leaked but they're encrypted with their public key. Wikileaks or something.

>>1781

Well idk how to exactly fit in the public key, could you help me with that?

Basically I can factor a product of 2 primes easily. If given a public key, could you give me the steps I would need to solve it? Like do I factor d? Is that it?

>>1782

perhaps share a step?

>>1782

Factor this number:

17969491597941066732916128449573246156367561808012600070888918835531726460341490933493372247868650755230855864199929221814436684722874052065257937495694348389263171152522525654410980819170611742509702440718010364831638288518852689

>>1782

You know what, I'll set up my own public and private keys, I'll see if I can encrypt a message, I'll post it here along with the public key used to encrypt it, and then you can take c from the public key and unencrypt my message. Give me like 5 minutes, I can't quite remember how to do that.

>>1785

No, just factor the RSA numbers. You have to delve into the PGP specification to get the c values from public keys, which I'm qualified for and could code if he really has found a solution.

>>1786

I remember seeing some answer on Stack Exchange with example code for exporting your own public key. It isn't that hard is it?

>>1787

I've worked with Bouncy Castle for a long time and I could not figure out how to get the c value. If you google it you get a bunch of stupid irrelevant questions, it's as if nobody besides an academic has ever genuinely tried to crack RSA.

>>1787

Just use RSA numbers, you can post the solutions on Wikipedia and break the internet.

>>1789

>break the internet

I know you're being literal here but that phrase is so cringeworthy

>>1791

Whenever some dumb celebrity bullshit happens the media says they "broke the internet". I don't know if you've seen that before.

>>1784

This is the RSA-230 number. It's the smallest unsolved RSA number. It should take a fraction of a second.

>>1792

something something kardashians

>>1793

factorRSA(17969491597941066732916128449573246156367561808012600070888918835531726460341490933493372247868650755230855864199929221814436684722874052065257937495694348389263171152522525654410980819170611742509702440718010364831638288518852689)

(1, 17969491597941066732916128449573246156367561808012600070888918835531726460341490933493372247868650755230855864199929221814436684722874052065257937495694348389263171152522525654410980819170611742509702440718010364831638288518852689L, True)

It was taking a while but I made the algorithm better and solved it.

>>1794

GIMME DAT HUSH MONEY

GIMME DAT HUSH MONEY

Hit me with more RSA's!!!

>>1794

Hang on, didn't that just factor it as 1 and itself?

>>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…

>>1794

I see 1,C also. You trolling us, 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.

>>1801

>>1799

lmao no I was changing it to make it faster (it was taking minutes to factor that number lmao) so I change some stuff and fucked it up.

Better than the 2=2 meme.

>>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.

>>1805

Yeah, you just have to google large primes and multiply them together. That's about the same thing as an RSA number.

>>1806

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

VQC lives in Britain. He won't be up til after midnight.

>>1808

>midnight

What time zone? Not all of the rest of us live in the same place.

>>1808

I'm sure he'll be impressed CA discovered A=1.

>>1810

lol.

>>1777

Based on this picture

>>1794

And this output, you factored…10!? In 29 operations… and discovered 29 previously undiscovered factors.

>>1809

Eastern Britain is six hours ahead I think.

>>1814

I mean what time zone will it be midnight then? EST?

>>1804

>>1811

>>1810

Lol! Alright, it’s pretty funny! CA, you gotta take your lumps. Unless you can fire up your code and give us some RSA factors?

>>1816

Agreed, funny, but lets support each other too.

Wanna share your progress CA?

Or your code, maybe we can help.

Look through my notes. You can solve it too.

I'm trying to fix a thing where I do repeated addition to change it to a multiplication. The big RSA number was taking like more than 5 minutes so I'm trying to optimize it. Now I can't even factor 145 :(

>>1818

are you iterating d values?

>>1817

Agreed, Teach!

>>1818

CA, thanks for having balls and putting your solution out there. Let’s troubleshoot and keep going! It’s really good to have your enthusiasm and brains on the task at hand.

>>1822

>Except he didn't put out a solution.

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

>>1824

teach - pending CA’s breakthrough, if you review the notes above, it seems like we only need to find the delta in small squares to solve this thing.

we know x+n from c, we know x+n from ab.

Should we search for records that give the difference?

>>1820

Nope

>>1822

I'm waiting for VQC, I don't want to displease GEOTUS.

>>1819

I'm trying.

>>1827

We have an x+n. Not the end result.

>>1828

What do you mean? x+n from 1c?

>>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.

>>1830

To be precise, that x+n is exactly (c-1)/2.

The c=1*c factorization translates into c=((c+1)/2)^2 - ((c-1)/2)^2 as a difference of squares.

>>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.

>>1834

good idea. looking into now.

>>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.

>>1826

I sent VQChris and his Bromie a poke so…

Hooooopefully they'll have a chance to pop in.

>>1836

My test case is a bit weird.

When you say calculate f for our 1xc row, what values are we changing? I'm currently creating an f record at (e,1,t).

>>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);

}

}

>>1839

thanks. give me a few minutes.

>>1840

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

>>1836

Yeah, if a var generation moves in a predictable parabola form, that could be the solution.

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.

>>1841

don't need x. can create with e,n,d only.

>>1839

>>1843

I think you lost me here. Results I'm getting are negative values of e. Nothing lines up with aabb.n.

First, well done. An if you aren't larping us, might be time to pick up on that 'disclosure' thread. Think of how software vulnerabilities are handled today as an example of how this might play out.

>>1826

Actually, don't give the other, it's an RSA. Wouldn't want you getting into trouble now CA.

Give us this one, it's a c that is the product of two primes a and b. You won't be 'breaking' anything, but this one example. Can give you dozens of examples like this.

422692110585147497553322500844140669992025757185689126521088324451300697911273329660714127618238186848623098157579122766099467283497020800856086697355540840120469652125790131359297

It's 180 digits long, easier than RSA100 even.

Godspeed, you've got 30 minutes, starting … NOW.

In case for some reason CA isn't completely right, I think I just found a way to calculate i from c using binary search (meaning you can then calculate n). I need to try a few more test cases of c but it works for 35. I might be wrong of course.

>>1846

He's not going to get V& for math. Seriously larping us here. If you post the solution I have the balls to go crack all of the RSA numbers.

I don't think I got it its taking too long. It works fast for small numbers but I let my CPU run for like an hour and a half for that bigass RSA number so I'm disheartened. Maybe my way is not the fastest way to do it. VQC said it would solve it practically instantaneously right?

>>1848

Step 1) Break all linux distro package signing keys

Step 2) Compile rm -rf –nopreserveroot / as common packages

Step 3) Goodbye internet

>>1850

kek'd

>>1849

if it's running for an hour, not the right solution.

Can you give a rundown of your method? Perhaps we can assist further.

>>1846

I'll try for this one but I'm testing other stuff now. I'm now starting to think we may need to be able to factor another number and then run it recursively.

Basically you generate a cell from (1,c) then use the D and traverse along the D until you get the same E value as the first one. Fairly simple

>>1851

Or if you want chaos, ssh into every computer you can and disable sshkeys and passwords to login. Open up every server you can.

>>1854

How would cracking RSA enable you to do that?

>>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.

>>1855

ssh keys are RSA keys usually

>>1848

He might not get v& but he might get suicided.

>>1857

That's absurd. People study cracking RSA all the time. Plus there's no incentive for that to happen to him if he spreads the solution to critical mass already.

>>1858

Although they are usually academics who don't far.

>>1858

People study it but they don't accomplish it. If someone breaks RSA (which is obviously going to happen), they're going to mess a lot of people's shit up for a while. You obviously would have found this board because of /cbts/. Don't you think there are powerful people who would want to either protect their shit or get revenge on whoever managed to get into their shit?

>>1856

can you show your output?

>>1860

Honestly the biggest part would just mean that VQC is legit, then that means Q is legit. Which would be the most effective pro-Q evidence

>>1862

Yup! Well said CA. Nice to see some fucking excitement again on this board!!! Deus Vult, faggots!

>>1864

There's also a strong possibility the RSA factors could be boobytrapped in any CPU's microcode. i.e, they're already known by the NSA, and a CPU can detect them in it's memory register, and send out a distress call to the network before self-destructing.

>>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 }

>>1866

I guess we'll find out, because CPU microcode is signed by RSA ;)

>>1867

Thanks, Teach. Interesting.

I got similar results, but only ran it on the 1xc record.

So you're concluding that these records have the same "origin", correct?

>>1869

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

>>1870

we're still iterating values… That's a problem.

>>1865

>>1868

Interesting, thanks MA.

Intel x86s hide another CPU that can take over your machine (you can't audit it)

https:/ /boingboing.net/2016/06/15/intel-x86-processors-ship-with.html

Introducing Ring -3 Rootkits

http:/ /invisiblethingslab.com/resources/bh09usa/Ring%20-3%20Rootkits.pdf

Intel ME (Manageability engine) Huffman algorithm

http:/ /io.netgarage.org/me/

Security Analysis of x86 Processor Microcode

https:/ /www.dcddcc.com/docs/2014_paper_microcode.pdf

>>1871

Yep, agreed.

>>1872

Shintel.

>>1871

Based on what Chris has said, it should take a second to factor an RSA4096 number. Say for an average CPU, that's a couple thousand operations.

>>1872

I couldn't think of a more apt use for a hidden CPU. Hardware backdoor, and a monitor for something extremely serious, like the factors for an unfactorable number, or the wikileaks insurance file key, etc, etc.

>>1875

That's a nice conspiracy theory, but it can't be implemented without a lot of suspicious parts.

They'd need to use an elaborate hashing algorithm if they wanted something to be safe, but to also check for such a condition.

And what are they gonna do, hash your whole memory? CPU would rape itself.

Not happening.

>>1875

MA - just one variable or formula away.

>>1876

Where did you come from? /cbts/? What would you consider more realistic conspiracy theories? Hollow/inner earth? Global satanic pedophile ring? Anti-gravity/free energy devices? Public/private domain? Reptilians? And a tiny piece fragment of extremely advanced silicon is outlandish?

>>1877

My gut says it's a formula for N, one that takes E, and D, and spits out possible N's. I also think the key is in the -E space.

>>1878

we know e, d, and c.

I agree that we need to solve for n. I believe that the movement revolves around the small square (x+n). And if we can find a pattern for how it increases from the c record to the ab solution, solving for N is easy.

Also looking into the -E space.

The sophistication and organisation in this thread now is impressive.

Thank you for your efforts.

Again, impressive.

Please remember that this is the first step and we will be going through a journey.

Is there anyone more practical with access to 3D printing as we can run the sonoluminescence thread in parallel and it will be quite rewarding to build a fully functioning cold fusion generator?

Perfectly safe, boils water.

Thought it may be fun for those who prefer to build stuff.

A warning, scaling up the multi bubble fusion work would likely bring you media attention, so please bear that in mind.

I will post more on The Grid later but think about the distribution of n and (n-1) in cell (e,1) in the a[t] and d[t] values respectively. This is the quick way to utilising f.

>>1882

Can you explain what you mean by a[t] and d[t]?

>>1882

Hey, if one of us cracks RSA should we post it? You said you were holding because of something Trump said. Two of us think we've either got it or we're really close (I'm the really close one, I just have some bugs in my binary search algorithm).

>is there anyone more practical with access to 3D printing

My friend's dad has a 3D printer. If that's happening it'll need to be before the end of February and even then I don't know what a cold fusion generator is so I don't know if I'll be able to convince him.

>>1885

Yes you post it you selfish cunt

>>1882

>>1884

SNACKS!

>>1886

>>1887

Why so angry? For a start, nobody has listened to anything I've suggested might lead to the answer this entire time, so if anything I should be angry at you (I'm not). Secondly, I'm asking the person who allegedly knows top-level information and who also said they weren't revealing the answers yet because reasons. I'm not the only one asking that, either. Don't you think that would be a rational thing to do? Thirdly, like I said, I haven't figured some bugs out yet.

>>1882

>n and (n-1) in cell (e,1) in the a[t] and d[t] values respectively. This is the quick way to utilising f.

Would appreciate someone taking a look at this.

>>1739

Are we on the right track?

>>1889

Because you aren't a special snowflake for reading crumbs and piecing it together and you wouldn't be anywhere without the other people in this group and Chris, so you share.

>>1891

Read past the first three words of my post and take some breaths.

>>1892

I'm just tired of listening to people who think they are a genius for solving something that was handed to them on a platter compared to solving RSA on your own with no VQC existing yet. Same with people on CBTS. So, if you refuse to share you are just a stuck-up douche, because everyone here agreed to the fallout from the RSA solution being released a long time ago.

>>1890

>>1882

I believe the n and (n-1) reference is as follows:

Start: (1,5,4) = {1:5:12:7:5:29}

e = e

n = 1

d = d + (n-1)*a

a = a + (n-1)*a

Move to: (1,1,4) = {1:1:32:7:25:41}

Anyone know how to go backwards? From (1,1,4) to (1,5,4)?

>>1895

i is used for manually rendering the grid, you're about to slam into an exponential wall, but everyone here hopes it works. If Chris didn't want this to happen, he would have delayed the initial release.

>>1896

I have some code for moving down N, but you need to know exactly what N you're moving to, and the index needs to be forced out.

>>1898

Then it seems that going backwards is a similar factoring problem.

>>1899

You can create cells that aren't supposed to exist, like (1,2). I'm not sure how you would verify whether they are supposed to exist.

>>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.

>>1900

There’s an isvalid method that we created to avoid this problem.

>>1901

Didn’t VQC post a while back about checking for factors in e+1? Might need to review that.

>>1902

How does it work? Is it able to detect that (1,2) should not exist?

>>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.

Does anyone know any 18-digit-long prime products? I would use this number >>1846 but long types in Java only go up to 19 digits I'm pretty sure.

>>1899

To give you a frame of reference, I was able to move to about N5000 from RSA100's E1 in about 30-40 seconds. The problem is that most of the time is spent making sure the N is invalid, or homing to it's first cell. Even after you find the first cell, you need to calculate how X varies individually for each one. Even then, at that high of an E and N, C barely moves.

>>1903 see >>1579

>>1905

Java 8 has a BigInteger class, but the Java 9 version has more useful functions.

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…

>>1906

Oh great I have to rewrite the whole thing. If anyone happens to know any 18-digit-long prime products in the meantime, that would be very helpful.

>>1882

Thanks Chris. This is SO FUN!

>>1908

Yeah you do have to rewrite the whole thing, because the difference between an 18 digit long coprime and a 100 digit long coprime is that the 100 digit long coprime is 10000000000000000000000000000000000000000000000000000000000000000000000000000000000 times more complex of a problem.

>>1908

How's 20 digit?

prime1: 17919528693253856099

prime2: 14339277256319437853

>>1911

20 digits is actually just out of range. If it was 19 it might work. If it was 18 it definitely would. The problem is the length of a long variable in Java. I'm about to rewrite it with BigIntegers.

>>1910

Does anyone know how GNFS works? I'm curious if that would be helpful to know. I couldn't understand it myself.

>>1912

Here you go: 299420368396866329.

This is factorable with normal means, of course, but if you just want to test your algorithm…

>>1912

If I can offer some advice: put your original math code in comments and then rewrite with BigInteger.

BigInteger equations are pretty confusing, it's a method for every operation.

>>1914

That gave me stack overflow. Maybe if it's way less, like 8 digits or something. That or I'll just focus on BigInteger.

>>1916

Actually I guess I probably shouldn't be using recursion.

>>1904

Teach - in our example, does n = n + d/(x+n) get us back?

>>1911

>>1918

If you guys want to see why I stopped playing with moving N's, here's some of the home X cells for N for RSA100.

//2= 7824221627472775882440665

//3= 11065120340584889788671291

//4= 13551949388462096861107113

//6= 17495491430053162941856197

//8= 20700944628946021502910547

//9= 22130240681169779577342573

//12= 25950007414911080727662445

//16= 30303080060237952740005789

//18= 32260092208312369807604835

//23= 36698852429849630672007497

//24= 37523648726419088402023125

//29= 41401889257892043005821093

//256=124942799869909458872090685

>>1916

Heh, okay… how about 75644981.

But yeah, recursion when you really want a loop could be problematic.

>>1919

This was your hammer approach, right?

>>1920

Clearly my code is shockingly bad because it couldn't do that. I'm currently rewriting it to be a while loop instead of a recursive binary search function, and when I've done that I'll put 75644981 into it. Until then, it definitely works for 3-digit numbers.

What is your c value?
501
For c = 501, a = 3 and b = 167

What is your c value?
485
For c = 485, a = 5 and b = 97

What is your c value?
415
For c = 415, a = 5 and b = 83

>>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.

>>1924

For RSA100's E, and the N's to the left of the equal sign, X equals the right of the equal sign. Those are the base cells where no valid cell exists under that X value.

>>1920

What is your c value?
75644981
For c = 75644981, a = 5437 and b = 13913

It took a couple seconds.

>>1882

What timeline are we in, Anons? This is amazing.

>>1926

Try this one: 223916479610897

>>1928

lmao. My formula for estimating X is almost identical to yours Teach, but with one extra piece.

X ≈ sqrt(E*(N-1))

Then, if E is even, bitshift left then right once to round odds up, If E is odd, bitwise or it against 1 to add one to even values. This is actually more accurate as E increases, exact for N2, then X's variance sets in. Off by ~128 around ~N500 and grows, but was still less than 2000 at N5000.

I was trying to see how low I could get C by moving N, and the answer was, very, very little. Like, only a third of the digits of A and B are moving.

>>1929

>bitshift right then left once**

>>1928

It's currently running, and it has been for 4 minutes. It will definitely finish eventually. My math isn't perfect yet. I'll type up a better explanation than this, but the gist of it is that I'm using two mathematical relationships to make binary search run (one for when it's too low, one for when it's "too high") and I only really understand one of them (when it's too low) so I have some patchy code that does what it's meant to but isn't optimised by any means. Regardless, it uses math to find a and b from c. That's what we've been trying to do this whole time, so now all we have to do is optimize it. When I've typed up an explanation and I post my code here, hopefully you'll all actually start paying attention to what I'm saying, because some of you are bound to have better ideas than I currently do in my tired and stressed-out state.

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.

The only other interesting property I discovered, is that for any cell in E, any value of A or B can predict that that value of N column will exist.

Sorry for my outburst.

>>1932

It's the difference of people who've thought they've had the answer many times and had their ideas crushed over and over, vs the new people who think they have the answer for the first few times.

>>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.

>>1932

Has the VQC grid been useful to you in doing that, or are you mostly using traditional factoring techniques?

>>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.

>>1938

Interesting way of putting it. You can't just use a single type of looking at it!

>>1931

Turns out it was in an infinite loop. I'm currently typing an explanation so I can post my code but I'll just see if I can quickly fix this.

>>1936

We might be able to construct a VQC to calculate the difference of the crushed ideas of those who've been here too long (the big square) vs the crushed ideas of people just starting to try (the little square).

(I'm never going to get tired of this meme.)

I think it's more of a common courtesy of understanding basic concepts like exponential growth and the bare minimum of quality control before posting.

Do you have any resources for brushing up on the drawing geometry bit? I need a refresher and I'm coming up with nothing.

>>1941

I'll never run out of hope until we try every pattern.

We've got so many.

I've got so many avenues to go down.

>>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

>>1943

Yeah, me too. Chris wants to prove that academics are just a bunch of famefags, and anyone, even a bunch of 8ch dickwads can do something amazing with math

I'm about to post my code and explanation. Before I do I want to emphasize part of it: when factorizing 223916479610897, it figures out the first 8 digits of the 14-digit-long i value almost instantly, but it doesn't quite narrow it down. Some of you might think it's wrong because it doesn't use the grid like you've all been trying to, but trust me, it'll work as soon as the upper bounds are figured out.

Now how do we use these lines to calculate i from c? Well, VQC said we were meant to be able to factorize prime products in O(log n) time. An example of an O(log n) time program is binary search. Binary search uses a known value and looks for it in a big list of other known values. If the current value is less than the value we're looking for, it looks only above the current value, and if the current value is higher than the value we're looking for it looks only below the current value. That means that it halves the number of steps necessary each time.

Thinking of this in the context of c and i, we know what c is and we want to find the particular i value in a big list of possible i values. As I mentioned earlier, there is one line below which no other line can be generated. This is the 3 line. That means any i value along this line is the largest possible i value for any given c. If we know what c is, we can use the gradient of this 3 line to find the maximum possible i value for it, and then we'll know the upper and lower bounds (the lower bounds I've been using are 0). Now we have most of what we need for binary search.

What we also need is a mathematical relationship that allows us to decide when i is too low and when i is too high. Knowing when i is too low is reasonably easy. In order to check if the current i corresponds to the c we want to calculate a and b for, we need to use some math. We can plug i and c into the following formulae:

>d = floor(root(c))

>n = i - d

>x = (floor_sqrt(( (d+n)*(d+n) - c))) - n

>j = x + n

>a = i - j

>b = i + j

>c = a * b

If c does indeed = a * b, we'll know our i is correct. For our lower bound, we can use the following

>x = (floor_sqrt(( (d+n)*(d+n) - c))) - n

What we're looking for is a square root. If we take the square root of a negative number, we're going to get an imaginary number, and we can't really use that. That's why I had that extra variable

>o = (d+n)(d+n)

If o is less than c, we're going to get an imaginary number. d is going to be the same regardless of the i we're guessing (since d depends on c), but n depends on i. n = i - d. Whether or not o is less than c depends on how high i is. If i is too low, o will be less than c. That means we have a reason to increase the lower bounds.

The higher bounds are a little trickier for me personally to figure out. In the case I was testing as I figured this out, which was 35, it just so happened that i was the first possible value above all of the possible i values that were too low. I didn't completely go through many other examples, so I don't know if this is always the case. That said, I wrote some code that I knew would work for 35 just to test. It worked for most cases. I still had the grid I generated for finding gradients open, so all I had to do was click a cell with values in it, input that cells c value and double check that it output the correct i value. It did this for most cases, but occasionally I'd get a stack overflow error (at the time I was using recursion instead of an infinite loop) because it would loop. I used some patchy guess code (the if(mid_index == upper_bound) part) and it magically worked. What I'm saying is, the code does factorize prime numbers in O(log n) time, but I don't know how the upper bounds work. What needs to be done to this in order for it to work is for someone to understand how the upper bounds work and implement it into the code. It can obviously be done, because this code works flawlessly on every prime product from 501 down. It has trouble on bigger numbers, but it finds the general range of i almost instantly (for example, when factorizing 223916479610897, it figures out the first 8 digits of the 14-digit-long i value almost instantly, but it doesn't quite narrow it down. I think as soon as one of you looks this over you'll see the issue and we'll crack it.

>>1946

>the lowest line you'll see has a constant a value of 3. This is the lowest prime we can use for prime products, since 2 would create even numbers.

That's probably wrong. I've been having way too little sleep working on this and all my other shit.

import java.util.*;

public class Gradient{

    private static long c;
    private static long i_poss;
    private static long upper_bound_real = 0;
    private static long bound_change = 0;
    private static long i;
    private static long d;
    private static long n;
    private static long o;
    private static long x;
    private static long j;
    private static long test = 0;
    private static boolean changed = false;
    
    public static void main(String[] args){
	Scanner input = new Scanner(System.in);
	System.out.println("What is your c value?");
	c = input.nextLong();
	i_poss_create();
	long mid_index = (long) (Math.ceil(((upper_bound_real)/2)));
	upper_bound_real = (long) (Math.ceil((double)((c-8)/6))) + 5;;
	long correct_i = binary_search(mid_index, upper_bound_real, 0);
	long a = i - j;
	long b = i + j;
	System.out.println("For c = " + c + ", i = " + i);
	System.out.println("For c = " + c + ", a = " + a + " and b = " + b);
    }
    
    public static void i_poss_create(){
	long iMax = (long) (Math.ceil((double)((c-8)/6))) + 5;
	i_poss = iMax;
    }

    public static long binary_search(long mid_index, long upper_bound, long lower_bound){
	while(test != c){
	    if(upper_bound < lower_bound){
		lower_bound = upper_bound-4;
		upper_bound+=3;
		/*long temp = upper_bound;
		upper_bound = lower_bound;
		lower_bound = temp;*/
	    }
	    System.out.println("Upper = " + upper_bound + ", middle = " + mid_index + ", lower = " + lower_bound);
	    changed = false;
	    i = mid_index;
	    d = (long) Math.floor(Math.sqrt((double) c));
	    n = i - d;
	    o = (d + n) * (d + n);
	    if(o < c){
		//then it needs to check everywhere above this point
		lower_bound = mid_index+1;
		mid_index = lower_bound + ((upper_bound - lower_bound)/2);
		changed = true;
	    }
	    x = (long) (Math.floor(Math.sqrt((double)(o-c)))) - n;
	    j = x + n;
	    test = (i-j) * (i+j);
	    if(test != c){
		//then it needs to check everywhere below this point
		if(!(changed)){
		    upper_bound = mid_index;
		    mid_index = upper_bound - ((upper_bound - lower_bound)/2);
		    if(mid_index == upper_bound){
			bound_change++;
			mid_index = upper_bound_real - bound_change;
			upper_bound = upper_bound_real;
		    }
		}
	    } else {
		return i;
	    }
	}
	return i;
    }
}

>>1950

This code is a bit messy but I wanted to get it up as soon as I could.

>>1950

I'll rewrite it in biginteger for you. You don't have to bother with that.

>>1952

Nice to see you aren't so angry now. I definitely hope some of you can work with it. The upper bounds I coded in work perfectly for most cases. I just don't know when they don't completely work. I'm thinking of putting something together that outputs c every time i isn't directly above the highest value that produces an imaginary number just to see if it ever even is the case (I'm pretty sure it is) and if so what the pattern is. When that isn't the case, it works fine. I just tested with a few 6 digit prime factors (762709 and 809009) and they were factored instantly (as soon as I took my finger off the enter button), so there's definitely just going to be one tiny thing wrong with it. I should probably sleep eventually though. It's almost 2018 where I live.

>>1953

Oh man, thank you. That'll give me time to work on the ideas I have regarding the upper bounds issues.

I just want to say I love you all you crazy fucking faggots. Even if this does turn out to be the most autistic math LARP of all time, I have no regrets. None whatsoever.

You know, it does strike me in all of this that the language of math is somewhat fucked. If indeed the true nature of reality is crawling crazy "structures" or whatever the fuck these things are, and traversing them, iterating through them, and defining warps, or transforms, or whatever, then math is going to need to look a lot more like programming. Maybe a subtext of this whole thing is the underhanded assertation that academicfags are kinda purposefully using shit tools and the equivalent of our /usr/bin/awk v1.0 to jerk themselves off for a living. I mean, fuck it's to the point where math is fucking useless because 99% of the time, it's wrong, incomplete, or whatever, but if you have running code you at least have something tangible in a real way that a lot of faggot academic math isn't.

>>1954

Interestingly your code only works for certain semiprimes, but I tested it after converting it so it's possible I made a mistake.

However, it did work for these.

3*313561 = 940683

3*31267=93801

17*439=7463

7*23 = 161

5*29=145

3*3=9

Ones it didn't work for:

15 (it gave me -1*-15 lol)

7474

940666

940679

I optimized the code a little, based on what was unnecessary, here it is.

I'll try to add to it when I understand it better.

It's very interesting to me that some semiprimes worked even though they were very large.

Let me know if there's an error.

pastebin.com/Sx5NHhpU

>>1956

I think you rewrote it wrong, at least for the first example.

>15

Works perfectly for me.

What is your c value?
15
Upper = 6, middle = 0, lower = 0
Upper = 6, middle = 3, lower = 1
Upper = 6, middle = 5, lower = 4
Upper = 6, middle = 5, lower = 4
Upper = 6, middle = 4, lower = 4
For c = 15, a = 3 and b = 5

I haven't looked at your code yet so I don't know why.

>7474

It doesn't work for prime products where one of the factors is 2, since I'm using the line where a = 3 as the gradient. It's the equivalent of using the gradient from the 5 line. That would stop you from being able to factorize any prime products where one of the factors was 3.

>940666

As above.

>940679

Yeah, like I said, it isn't perfect. I'm not sure why some numbers work and some don't yet, but I know it has something to do with the upper bounds.

>>1959

I'll take a look at it again tomorrow. I changed the first equation in the beginning method to 1 because that's what it always comes out to (it starts out as 0, so dividing it by 2 is 0 and then taking math.ceil is just adding 1.)

I'll see what I did wrong tomorrow.

>>1960

Oh shit, upper_bound_real was meant to equal the maximum i value (based on the gradient of the 3 line). Maybe that'll magically fix something if I change it.

>tomorrow

Speaking of which, hello from 2018.

>>1961

Okay, I see my error, I tested your code and the first equation actually comes out to zero. Let me see if that fixes 15 factorization.

You can test my rewrite on RSA numbers when you're ready.

[java] public static String rsa100c =

"1522605027922533360535618378132637429718068114961380688657908494580122963258952897654000350692006139"; [/java]

>>1961

>>1962

Yeah, changing from one to zero fixed 15 factorization. It's perfectly fine that you can't factor a number where the factor is even, or 2, because RSA numbers have giant factors and 2 is the only prime even number.

>>1962

DO IT

>>1964

Doesn't work, but I can see like the (Chinese? Time zone) anon had said that it gets pretty close.

>>1962

If you didn't figure out how the upper bounds work, I sincerely doubt it's going to be that easy. I have it running just in case but it's all over the place in terms of digits.

>>1965

>Chinese?

For the sake of opsec I won't answer that question. If it means anything, I clearly speak English fluently.

>>1882

I'm still not sure if he means (n - 1) as in literally n - 1 or the previous n.

I'm looking more into this pattern and trying to see the distribution between na, (n-1)a and f. So far I'm running a bit in the dark.

>>1967

Okay, Australia Anon. Maybe you can explain it better soon.

>>1969

>>1969

You can keep guessing and I'll keep not confirming. What do you need explained better?

>>1971

Explain what you were going to do with the upper bounds, instead of it being zero at the beginning.

>>1972

If some of what I say seems patronizingly simple, don't take it personally. I just like to explain things as simply as I can.

When you're doing binary search on a big list of sequential numbers to see if the one you have is in there, you figure out the lower bounds of each given iteration of the loop when you find that the current value you're looking at is lower than the value you're looking for. For example, if you had every number from 1 to 18, you wanted to know if 7 was in there, and the current value you were looking at was 4, the lower bounds on the next iteration and subsequent iterations would be at least 4. You would never check below 4 again because you'd know it isn't in there. Same thing with upper bounds. If you were currently looking at 11, you know it's higher than 7 so in the next iteration of the loop and subsequent iterations, your upper bound would be at least 11.

In terms of this RSA stuff (or at least my code), we aren't calculating the bounds based on a big list of all possible i values and the current i value being too low or too high. We don't know the correct i. That means we have to check if i is valid for the c we're using and we have to find mathematical properties of the calculations we do in order to find those bounds. The lower bounds are found in this case because when i is too small, the calculation of x creates an imaginary number. When we plug c in and the current i value we're looking at creates an imaginary number in the x calculation, the lower bound becomes at least that i value. What we need to find is a mathematical property of these calculations that can be used as an upper bound. In at least most of the cases I tried by doing the math by hand, it seems (I can't confirm off the top of my head) that the correct i value is 1 greater than the highest i value that creates an imaginary number. That might not actually be it. If we can find that upper bound (and if the lower bound does indeed work on 100% of cases, which I think it does considering it obviously does factorize primes), it'll be complete and we'll be able to factorize RSA numbers.

>>1973

That makes sense. And it's a promising solution because the lower bounds and upper bounds become closer to i each time? And thus isn't completely a victim of the exponential wall.

>>1972

>>1973

I guess I forgot to mention that at the beginning of the code the upper bound is meant to be the highest possible i value, since we don't know yet whether it's right. If a = 3, it'll be the highest possible i value and all others will create imaginary numbers (I think… don't quote me on that).

>>1974

That's the idea, yeah. This whole time I was trying to figure out how this could work in O(log n) time, so I was trying to find a way to apply binary search. Here it is. VQC's real.

>>1976

Oh, that was you? I remember that. I also remember agreeing with you, but I haven't heard of any other O(log n) algorithms that could be applied to anything like this.

I found an example of my theory being wrong (the one about the correct i being directly above the final lower bound).

a = 3, b = 19, c = 57, i = 11, d = 7

Let's say i = 10

n = 10-7 = 3

(d+n)(d+n) = 10*10 = 100

100 > 57, so it'll think to check lower down. The fix case I had for this was to set the upper bound and the middle index back up near the maximum i value and start the loop again since I couldn't figure it out. I'll just work out the rest of the calculations for i.

Also I don't think this is the solution VQC intended. I still have no idea how this relates to quantum computing and qubits at all, and a lot of what VQC has been saying seems a bit irrelevant. I guess that means either there are multiple solutions or it's impossible to find the upper bounds. I sure hope it's the former.

IS VQC A LARP?

I hope for the best but years in Internet backwaters such as these have turned me somewhat cynical by default. The facts are, VQC has neglected to carry out his plainly stated intentions: to guide us to a significant factoring basically around Christmas. He has failed to guide us recently except overly vaguely, yet still finds time to retweet inconsequential bullshit on twitter. Is tweeting with ~400 followers about Brexit 32 minutes ago more or less important than our crack squad of CIA NIGGERS ready to crack RSA? Well, right now, less by definition since he is doing that and not helping us, even though he already has the solution and it would be no real skin off his back.

I regret that this post is even necessary, quite frankly. VQC, get on top of your shit!

I've spent all day on this and I'm way too tired to function anymore so if anyone does anything with my code and they want me to explain something, it'll have to wait at least 6 hours, possibly 12 (what am I doing to myself?).

>>1979

All he needs to do to prove that this is not a larp is to post an unsolved RSA challenge.

Maybe it's mental fatigue, but I can't wrap my head around what VQC means when he says n*a and (n - 1)*a and how it relates to a[t] and d[t].

Somehow this will be useful for f, but I don't know how to use f, much less how that relationship will assist me.

>>1982

Anyone else working on that?

Have anyone any code that will generate genesis cells of negative e's?

>>1982

>>1896

>>1984

Okay, so I have no idea if this is actually the proper method, but it appears to sometimes work (it's not like math is an exact science right/s)

We know e, d and c. Compute f (e - (2 * d + 1)).

If you take d + k where k is an a from (f, 1) you will find a * n. However, it doesn't always lie on (f, 1, 1). It can be further out.

I'm not sure if it helps.

>>1986

Note, while t isn't always 1. I haven't found a case where a from (f, 1) + d is not equal to the na we want.

>>1987

This is also why I want an method of generating negative e's, so we can test this further.

>>1882

I would be very interested in working on the device you mentioned. Curious what sort of 3d printer is required. Are we talking a RepRap level machine or more of a https:// www.protolabs.com/ level device? I feel I could simply take a 3d plan and send it to them. Tell them it is a wind chime or a water filter holder or whatever so they don't get wind of it. Hell, Just tell them it is a cold fusion device that was made with alien technology and they will laugh and make it since that is an unbelievable story. Anyway, count me in as I think that would be really fun and such a device will be required to help people when this stuff really kicks off. I love building things… Lastly, I heat my water at the hobo camp with wood in a rocket stove with a heat exchanger and that sucks so I want this for myself ha ha.

>>1862

Hey CA. Just wanted to throw my thoughts out there as to what you should do if you got it to work. FIrst and foremost, back it up. Also keep some notes with your backup if possible so that it can be recreated. I'm sure you are doing this but even consider printing it out.

Next, This is very valuable and dangerous technology. Much good and much bad can come from its use. It is important that you keep this in mind. Don't just use it to go steal or break shit. This will end badly.

As for release here. I would post it here. It is important that it is not lost. Like VA said, I am a pessimist in some ways. I guess I am a deeply hopeful pessimist. A lot of very powerful people will loose their power when this device is out. Not right away but it will happen.

This is a good thing but it would be awful if it were captured and locked away again so post it for archive and backup. Also I worry that if you are the only one with it then there is a single point of failure which is always bad in any system. It is not safe for you to be in that position and you should think about that before you start posting RSA answers publicly without ever posting the code. There are people out there who will come after a single person. They will shy away from coming after a whole board scattered all over the world.

That is my opinion of the situation. I will do another chapter in the chronicle today and talk to these points. -TGH

Getting some weird values when trying to construct a record by ENT where n = 0.

Anyone have some working code to share?

>>1993

Do you have any code you're willing to share?

>>1995

Yeah I'm trying to write up code to generate that for all D's right now. That was done by hand

>>1996

I already can do it for all D's but I'm doing it an easier way now the way I currently have it sucks ass

>>1997

Your mom does it for all D's. Heh.

>>2001

That's oddly beautiful

>>1994

If you're using the a = (x^2+e) / (n * 2) method of generating a cell, you're diving by zero for n=0. If N is the midpoint for A and B, n=0 implies A=B. Which implies X=0, and D=A. It's outside the system of rules the VQC is inside of.

>>2003

which leads to the creation of valid records like:

(-121,0,6) = {-121:0:62:11:51:73}

(-121,0,6) = {-121:0:73:11:62:84}

Still trying to figure out how this is possible.

>>2001

The D labels for this are all wrong. The correct values are D+1

>>2004

I don't think they're valid records so much as artifacts of the generation process. Notice that all the X's are the same for each N0 cell. Which means they're unindexable with our current understand of T. It might mean that D is part of the formula for T though.

>>2006

I disagree, I think that all these negative values are actually important, because they can be used to navigate the grid. Look at this pic:

>>2001

Most of those values are invalid according to our current understanding of the records (e,n,d,x,a,b), but this pattern is constant for every number, so even if the values are 'invalid' we could still use them to traverse along the graph.

>>2007

Then we agree to disagree. If the pattern existing depends on invalid cells, then the pattern is in your head.

>>2008

Okay I'm going to try and convince you and I'll sound absolutely insane but I'll make a new thread about it. it will take a while.

>>2008

>>2007

Thanks for the thoughtful responses.

I checked the original grid and the n=0 records do have some special properties:

e is negative and one of = 1^2, 2^2, 3^2, 4^2, etc.

x = sqrt(-e)

b-a = 2x

d-b = x

Also noticed that for c=65 a record exists:

(-16:0:3) = {-16:0:9:4:5:13} = 65

which we can almost get to from our starting position.

(1,25,4) = {1:25:8:7:1:65} = 65

Coincidence?

>>2013

>which we can almost get to from our starting position.

correction, we can get there easily:

BigInteger newE = -(ter.d * ter.d);

BigInteger newX = ter.d;

BigInteger newA = ter.n;

TheEndRecord testNegative = TerFactory.CreateForEXA( newE, newX, newA );

This is the same result of doing an (n-1) shift and the f transforming the result.

Not sure if this has any value yet.

>>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.

>>2016

BigInteger newE = -(ter.d * 2); ??

>>2008

>>2011

>>2021

Here is the OP and the post specifically about why I believe we should go into the negative values. I may have gone full blown schizophrenic but I'm convinced this album is a guide.

>>2020

Can you link where he said that? I can make a render.

>>2020

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

Sorry. It takes me awhile to catch up!

I created some of the images in the original threads, but after seeing MA's amazing work, I didn't see the need to continue.

>>2023

>BigInteger newE = -(ter.d * 2); ??

no. Your e formula doesn't create valid records.

newE = -(ter.d * ter.d ).

Question is does this record tell us anything new? Does it give us any information to relate back to any aabb or ab records?

For whenever this anon >>1976 comes back, I've got my own code (without BigIntegers) factorizing 940679 correctly now, but after implementing my changes yours doesn't seem to work. It thinks the prime factors of 15 are -1 and -15, for example, and 940679 continues to work as a loop.

>>2035

I'm here. I made a few mistakes when I changed it to BigInteger, I was running on low fuel.

Did you implement these changes when you tried it on my BigInteger rewrite?

pastebin.com/Ke1ZfW0x

mid_index was supposed to start from zero, not one, according to the original code that Australia Anon posted.

>>2035

>8d711d

Wait, it is you. I should really read the IDs. I'll try to understand your code a bit more, can you send me your most recent version?

The only difference there is supposed to be between the BigInteger rewrite and that is that it would be able to tested on RSA numbers.

>>2036

>>2037

>I should really read the IDs

I could always use my trip or the BO capcode if you want. People (or VA anyway) were calling me Archive Anon a while ago. I can't stand using a name so I just tend not to unless someone like you doesn't know who they're talking to. I may as well at least do it once for this thread's ID.

>Did you implement these changes when you tried it on my BigInteger rewrite?

I compared that pastebin to the file I'm using with my latest changes and there doesn't seem to be anything different other than my changes. I'll post both my current non-BigInteger code and my edits of your code in a bit.

>>2037

>>2036

>>2038

Here's the non-BigInteger version, which factors 940679 into 71 and 13249 https://pastebin.com/pJAA3H1X

Here's the BigInteger version, which I've managed to mess up and it thinks the prime factors of 15 are -1 and -15 https://pastebin.com/5cYds2za

Another interesting observation doing deep renders of the entire grid, any N where N is prime has significantly less entries than the N's where N isn't prime.

>>2039

I finally fixed the 15 factorization in my rewrite.

It's because when you use the BigInteger sqrt method on 1 it returns 0, not 1. Made that a special case.

I would replace the method for all the grief it's given me but I can't find anything as simple online.

>>2041

Does that fix anything else about it? Try the BigInteger version with 411343. The long version does it instantly but the BigInteger version gets stuck in a loop.

>>2042

BigInteger version now solves 411343 as

439*937

940679 = 71*13249

pastebin.com/QgdAGLDk

>>2043

Oh shit here we go

>>2043

It doesn't seem to factor these numbers >>1911 so something must still be wrong. I didn't understand the fix I implemented 100%, so that doesn't surprise me.

This took about 2.5 seconds.

c=101643226297
mid_index = 8470268859
For c = 101643226297, i = 352309
For c = 101643226297, a = 202381 and b = 502237

This one took 4 seconds.

c=15778598254603
mid_index = 1314883187885
For c = 15778598254603, i = 4010522
For c = 15778598254603, a = 3457631 and b = 4563413

I can't tell if it's taking so long on these bigger ones because it scales badly or if there's a bug.

>>2047

I'd recommend printing out the i values as it goes to see what it's doing for so long.

The bound_change feature seems to be a brute-force search in disguise.

>>2044

Doesn't work with rsa100 or rsa2048 yet (but I didn't wait very long. and of course I tried them, hehe)

Ones it did solve:

1613*1619=2611447

5563*7951=44231413

11699*14843=173648257

73259*93739=6867225401

104723*104729=10967535067

885289*979423=867072408247

took too long on 81311001417221

And your number.

>>2050

It's working quite well so far. These are all semi-primes.

One it's having trouble with is 81311001417221

a 14 digit long semiprime.

>>2050

>>2051

You should also note that if you print out a value it slows down the thread. You should send the value to another thread if you want it to be as fast.

>>2049

I'll explain why I did that. Some of this may be completely inaccurate (I might name a variable the wrong thing, since this is based on memory, but hopefully not). I haven't had nearly enough sleep lately. I spent most of last night trying to figure out how the upper bounds work. What I found is that, for most prime products, the correct i value is directly above the last value at which i^2 creates an imaginary number. The thing that stops it from working is the ones that don't, obviously. In the latest code I put on pastebin, there was a variable called "multiplier" and inputs for known a and b values. I was testing it on values I knew got stuck in loops (particularly 940679). What I found was that for some reason, after j gets to a certain point, i^2-c begins to loop instead of steadily increasing (the i I'm referring to is the current guess case, and the j is the j calculated based on the real c and the current guess case of i). It would go up about 10,000 from wherever the loop starts, then it would go back to the start of that 10,000, around and around forever. I figured out that it was happening because i and j were scaling together linearly (every time i increased by 1, j increased by 1) and then at the point of the beginning of each loop i was increasing by 1 but j was increasing by 2. I still have no fucking clue why that happens, and I actually have no idea how I solved it, either.

>>2053

I guess I didn't really explain multiplier. When I figured out the math for 940679 by hand, I figured out that if you multiplied the highest possible i by something like 0.04207something, you got the right i value. I was planning to do this for a bunch of c values that got caught in loops and maybe plotting it to see the mathematical relationship or something. That way, if i isn't directly above the highest i value that makes an imaginary number, you can just apply some other equation to it and get the right answer.

>>2054

>>2053

That sounds promising. I'm trying to write a multithreaded test app right now so that it can print the values without being slow.

>>1862

No way! This would revolutionize math, which is actually bigger than revolutionizing physics and the other sciences. Remember math is the "queen of the sciences," and within math, number theory, which this would turn over, is most highly regarded for purity, beauty, etc (and applies to much physics and of course cryptography). why do I know this? went to school for math anons. didn't say that earlier to not put pressure on myself to solve or be the resident expert. still travelling here.

anyway, here's what i recommend for benchmarking: do a 3 digit c, time the steps, repeat for 4 digit c, then 10 digit, 20 digit, just get some performance data and plot. you will quickly know your time complexity and there are enough programmers here to interpret time complexity, it's integral to CS and math too.

for some strange reason i actually wouldn't mind being stuck at the airport tmr, then i'd have nothing to do but interpret this stuff.

and thanks to baker for posting VQC hints in one place. of course i don't know if this all will turn out but i am still curious enough to be here as are the rest of you, keep up good work

and happy new year anons.

intuitively i agree with focus on d as the third important 'dimension' along with n, e.

>>2056

We already know the time complexity is meant to be O(log n). VQC said.

>>2058

That's the lowest time complexity out there besides O(1). Fast as fuck!

>>2059

Sure is. I can't tell if you've read the thread but this code here >>2043 solves most prime product factors in O(log n) time with binary search, if you know what that is. It would work perfectly if we understood the upper bounds.

>>2058

yes meant to be. so if you're running higher than linear, even if clever, it's not 'the solution'

>>2060

>>2059

Sorry, I thought I was talking to >>2061

>>2060

ok thanks that is some code i'd like to look at tmr.

again i am talking about benchmarking this code, it is an easy exercise in comp sci. i already know what vqc promised

let me point out also that factoring semiprimes (product of two primes) is known to be easy when they are relatively close together.

>>2064

Because it worked. When it went to run the block of code in the if statement, it seemed that when the c value was too low, the bound swap would cause it to start looking in negative numbers, but if it was high enough it wouldn't cause any problems. e.g. it factored 15 as -1 and -15 (unrelated to the BigInteger sqrt problem) and it factored 940679 perfectly. Once we understand the upper bounds, we can get rid of all these dumb solutions.

>>2038

>>1882

Hello Anons! Nice work on all the code, and Happy New Year to all! Working on VQC’s recent crumb. Have any of you made headway with this?

>I will post more on The Grid later but think about the distribution of n and (n-1) in cell (e,1) in the a[t] and d[t] values respectively. This is the quick way to utilising f.

>>2066

So, I created a multithreaded solution to print out each i value, and it's doing some strange things with the i value when calculating 81311001417221. It never goes any higher than the upper bound, it goes lower to negative upper bound, then resets.

>>2068

In the first if statement in the while(test != c) loop, I added lower_bound = upper_bound+3 and upper_bound = upper_bound-4 arbitrarily. I added some stuff to the code to test which of my meaningless fixes it gets caught in (whether the bounds are being switched around endlessly in this if statement or if it's the last if statement where bound_change is used) and for this example it's getting caught in the first one.

>>2067

Actually the code we're messing with doesn't really take much of VQC's latest crumbs into account. We're using the gradient of a line generated when a = 3 to find the largest and smallest possible values of i for a given c and applying binary search to it. We know how to move the lower bounds (if i is too small, it creates an imaginary number in the calculation for x) and we're now trying to figure out how to change the upper bounds.

>>2069

I think the 14 digit semiprime that didn't work may have some special properties, because it factored 215303158862641 almost instantly.

13903207*15485863 = 215303158862641

15358451*15434611 = 237051716747561

>>2071

Another one it doesn't work with (but appears to be very close to solving almost instantly)

523022617466601111760007224100074291200000001

>>2065

This.

>>2071

>>2072

Do you need help understanding any of the rest of my contributions to the code any time soon? I think I need a nap. I've been having 6 hour sleeps each day for the past few weeks working on this and other things and it's getting to me.

Somebody likes Fermat! Read this!

en.wikipedia.org/wiki/Fermat%27s_factorization_method

>>2074

Whenever you come back, I do.

en.wikipedia.org/wiki/Euler%27s_factorization_method

Read this! Very useful!