You might be interested in the fact that a variant of this visual representation still works: https://www.juricho.me/files/masterarbeit-hyperelliptic_curv...
As an algebraic geometer, I have a minor correction: The graphic "examples of elliptic curves" features the singular curve y^2 = x^3. This is not an elliptic curves, because by definition elliptic curves are smooth.
I didn't think anyone would notice/care, but I'll tweak it to skip over that example.
Each point that you pick is going to have a different number of times it can be added to itself before it lands on a point that has the same x-value but different y-value, and then the "point addition" operation draws a vertical line and the point goes to infinity. The number of times you can add a point to itself before it happens and the cycle resets is called the point's "order".
Most of the points on the graph will repeat themselves after less than a dozen times. The one I picked repeats itself after 72 points, which is great because that's every point on the curve. I chose it by writing a little program that tried each point and returned the best one.
Compare that to a "real" curve like Curve25519: it has the base point at x=9 and can repeat itself over 2^252 times before repeating. The author of that curve used a different technique to find the point's order (obviously he didn't try adding the point to itself a trillion^6 times) but the idea's the same.
Many many thanks for this brilliantly depicted explanation!
Ot: I also looked up ulfheim after I realized your first name is Michael, not Ulf.
Unfortunately a few years ago a racist hate group also started using the name for their own purposes. Today I've started the process of moving all my hosts to a new domain name, xargs.org .
226 / 9
= (226*34) / (9*34)
= 7684 / 306
= 7684 / 1 (since 306 = 1 mod 61)
= 59 / 1 (since 7684 = 59 mod 61)
I think y3=2888/7 is a typo for 2888/27, which also equals 55 by a similar calculation (1/27 = 52 mod 61).https://gist.github.com/syncsynchalt/ed02e39ad7adc8580b1086f...
Looking at your comment the disconnect seems to be at the division step: when performing a division such as 226/9, look up or calculate the multiplicative inverse for 9 (you can use the table at https://curves.ulfheim.net/inverse61.html), which is 34, and multiply by that instead. This is explained at https://curves.ulfheim.net/#division-multiplicative-inverse
In F61, 226/9 = 226*34 = 7684 % 61 = 59.
In F61, 2888/27 = 2888*52 = 150176 % 61 = 55.
(you can also proactively reduce those numerators and calculate with some smaller numbers):
(226%61)/9 => 43/9
(2888%61)/27 => 21/27
You should mention the generic rule: P+(Q+R) = (P+Q)+R, even if it's much more tricky to show than P+(P+P)=(P+P)+P.
(pushed)
so we can create an isomorphism(?) between the field (Z_61, +, *) and points on a modular elliptic curve with a base point P using function g:= g(k) = k * P
g(k) is fast to compute with the doubling method, but the inverse requires brute force. Even if you know k_a * P and k_b * P, computing k_a * k_b * P is hard.
However, if you know k_a or k_b (either private key) you can easily find k_a * g(k_b) = k_b * g(k_a) = k_a * k_b * P.