What does the curve used in Bitcoin, secp256k1, look like?

58

29

I'm reading up on ECC curves and on many of them I see an illustration that looks like this

enter image description here

What does the comparable curve in Bitcoin look like, or are all curves generally the same?

halfbit

Posted 2014-02-09T16:47:59.710

Reputation: 12 166

Answers

75

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.

y² = x³ + 7 over Z257, -128 through 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.

y² = x³ + 7 over R, -128 through 128 y² = x³ + 7 over R, -8 through 8

Pieter Wuille

Posted 2014-02-09T16:47:59.710

Reputation: 64 874

excellent answer – Gewure – 2020-07-03T19:56:37.810

1I'm not familiar with the subscript notation with exponents. Z subscript: 2^256-2^32-977 (I'm learning this as I go along). What does that mean... perhaps "take the mod of.." or is it something to do with the definition of a field I do not yet understand. – halfbit – 2014-02-09T19:43:41.227

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 – 2014-02-09T19:50:07.317

Is there any way to visualize signatures, and that the corresponding "S" value has two valid values? Perhaps with a different field? I'm entertaining the idea of educating people about transaction malleability in an interactive demo site. – halfbit – 2014-02-13T16:55:55.110

6

Actually 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: http://en.wikipedia.org/wiki/Finite_field#Statement

– eldentyrell – 2014-03-07T03:53:11.837

11Technically, 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 – 2014-03-07T08:52:17.267

Related: I was also curious if there was any way to visualize the rendezvous points that create weak private keys http://bitcoin.stackexchange.com/a/23315/1878 but I suppose that would be difficult or impossible to do.

– halfbit – 2014-03-10T16:09:15.593

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 – 2014-06-21T18:22:10.903

1@pieter you wrote: "that 'intersects' 2 points of the curve, will intersect a third.". Image 3 in the original post seems to show a vertical line intersecting at P + Q ... but seemingly not at a 3rd point. I'm just curious how is the "if 2 then 3" rule applied in ECC. – carl crott – 2017-09-30T22:56:24.150

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 – 2017-09-30T22:59:15.427

Since a finite field is just a "wrap around", I am sure we can fit the original real numbers curve over some of those points in the finite field version -- those points where no wrap around happened. – Jus12 – 2017-12-31T14:12:24.937

23

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)

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

 Elliptic curve over F17

and here over F59 :

enter image description here

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.

enter image description here

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.

Badr Bellaj

Posted 2014-02-09T16:47:59.710

Reputation: 971