I'm reading up on ECC curves and on many of them I see an illustration that looks like this
What does the comparable curve in Bitcoin look like, or are all curves generally the same?
48
57
I'm afraid you won't like the answer.
These curves - including the secp256k1 curve, y2 = x3 + 7` - 'look' nice when evaluated in typical number fields (integers, reals, ...), but secp256k1 is defined over the field Z2256-232-977, which means the X and Y coordinates are 256-bit integers modulo a large number. Curves using such coordinates do not have nice continuity properties.
I've tried to plot this curve over a similar but much smaller field, Z28+1. Coordinates extend from -128 to 128.
Note that even though it may not make sense geometrically anymore, it still has all properties you need. A line (which means, a group of points with equation ay + bx + c = 0) that 'intersects' 2 points of the curve, will intersect a third. Tangent again has no geometric interpretation anymore, but you can still compute a local linear approximation for the curve equation in a given point, which will have the property of intersecting the curve in a second point.
To show you what you'd get if this were over the real numbers, here is a plot of the same curve equation for that case. Once with coordinates -128 through 128, once with -8 through 8.
-
2Yeah, Z modulo 2^256 - 2^32 - 977. Or written differently: the integers modulo 115792089237316195423570985008687907853269984665640564039457584007908834671663. In the simplified (first) plot above, I've used the numbers modulo 257 instead. – Pieter Wuille Feb 9 '14 at 19:50
-
3Actually secp256k1 is defined over a Galois field, not a ring of integers modulo a prime. Now, it turns out that the secp256k1 field is a prime field and therefore isomorphic to a ring of integers modulo a prime, but this is not true for all ECDSA curves -- in fact, the "sectXXXyZ" curves (for which much faster hardware exists than the "secpXXXyZ" curves) cannot be described using rings of integers. See this page for an explanation of why every finite field has a GF representation but only the prime fields have a a Z/pZ representation: en.wikipedia.org/wiki/Finite_field#Statement – eldentyrell Mar 7 '14 at 3:53
-
8Technically, every prime field is a Galois field. There indeed exist SEC curves defined over binary GF(2^n) Galois Fields, but this one is not. I'm not sure what you're trying to say here, the Galois representation of such a prime field is just GF(p^1). – Pieter Wuille Mar 7 '14 at 8:52
-
2@makerofthings7 Those rendezvous points are just nonsense. You can come up with any set of 'special' points and transformations that make those easier to find, but there is no reason why they'd be more likely than others. We also don't actively try to avoid very low number for private keys for example - yes, those are easier to find IF you start by trying to crack those, but as they are not more likely than others to generate, why would you start there? – Pieter Wuille Jun 21 '14 at 18:22
-
2@carlcrott You're right - there is one exception, namely straight vertical lines intersect in only 2 points. This is solved by adding a virtual point 'at infinity' to the curve, which serves as neutral element. The result is a mathematical group. – Pieter Wuille Sep 30 '17 at 22:59
18
you can check the Bitcoin doc https://en.bitcoin.it/wiki/Secp256k1 , there you will find some technical details about the secp256k1 used in bitcoin.
Below an illustration of the secp256k1's elliptic curve y2 = x3 + 7 over the real numbers (plot using www.desmos.com/calculator/ialhd71we3)
in the context of a finite field Zp, which greatly changes the ECC appearance but not its underlying equation or special properties. the picture below represents the same equation in a finite field F17 (the x and y values are integers between 0 and 17).
and here over F59 :
You will find an online opensource tool here https://cdn.rawgit.com/andreacorbellini/ecc/920b29a/interactive/modk-add.html which will help you to plot the graphe and to make addition or scalar multiplication on a EC. E.g plot over F97 with P+Q.
another good article to read about ECDSA in Bitcoin is https://github.com/bellaj/Bitcoin_Ethereum_docs/blob/6bffb47afae6a2a70903a26d215484cf8ff03859/ecdsa_bitcoin.pdf
secp256k1 was almost never used before Bitcoin became popular, but it is now gaining in popularity due to its several nice properties. Most commonly-used curves have a random structure, but secp256k1 was constructed in a special non-random way which allows for especially efficient computation. As a result, it is often more than 30% faster than other curves if the implementation is sufficiently optimized. Also, unlike the popular NIST curves, secp256k1's constants were selected in a predictable way, which significantly reduces the possibility that the curve's creator inserted any sort of backdoor into the curve.
