secp256k1 point arithmetic

What this page computes

This is a bare-metal playground for the group law of secp256k1, the elliptic curve Bitcoin uses. It offers three operations and nothing else:

• mul — scalar × generator: k · G, the operation that turns a private key into a public key.
• add — point + point: P + Q, the chord step of the group law.
• double — point doubled: 2 · P, the tangent step.

Everything is computed live on this server in pure PHP with GMP-backed big integers. The output shows the operands as they were parsed, the curve constants actually used, the resulting point, its parity, both standard serializations, whether the result is the point at infinity, and an independent on-curve check of the answer.

1. The curve and why its points form a group

secp256k1 is the set of pairs (x, y) with coordinates taken modulo the prime p that satisfy

plus one extra element, the point at infinity ∞. Because the equation is modular, this is not a smooth arch drawn on paper but a scattered set of roughly n points in a 256-bit-wide finite grid. The useful miracle is that you can define an addition on those points which is associative, commutative, has an identity (∞) and gives every point an inverse (−P). Any set with those four properties is an abelian group, and a group is exactly the structure you need in order to iterate an operation — which is what "multiply by an integer" means.

The inverse of a point is free: if (x, y) is on the curve then so is (x, −y), because the curve equation only contains y². So −P = (x, p − y). Note that p − y has the opposite parity from y, a fact the compressed encoding uses.

2. The group law, geometrically: chords and tangents

The classical construction works over the real numbers, where you can draw it. Take two points P and Q on the curve and draw the straight line through them. A cubic curve meets a line in exactly three points (counted with multiplicity), so there is a third intersection point R. Define the sum as R reflected across the x-axis:

Why the reflection? Because the reflection of a curve point is still on the curve, and without it the construction fails to be associative — the reflected version is the one that makes (P+Q)+R = P+(Q+R) hold. Three special cases are worth naming, because they are exactly where the implementation has to branch:

1. P = Q. There is no unique line through one point; the limiting case is the tangent line at P. That is the "tangent" in "chord and tangent" and it is what doubling computes.
2. Q = −P (same x, opposite y). The line through them is vertical, it meets the curve only at those two points, and the third intersection is the point at infinity. So P + (−P) = ∞, exactly as an additive inverse should.
3. P = ∞ or Q = ∞. Since ∞ is the identity, the sum is simply the other operand.

Over a finite field "the line through P and Q" is still meaningful — it is the set of points satisfying a linear equation mod p — and the same three-intersections argument holds. The drawing stops being useful, but the algebra does not.

3. The group law, algebraically

Division by a non-zero element mod p is multiplication by its modular inverse, so every "slope" below is a real, computable field element. With λ the slope of the chord (or tangent) through the points being added, and (x₃, y₃) the result:

That is the entire group law. Notice that x₃ depends only on λ and the two x coordinates, and that y₃ is then fixed by reflecting through the line. Notice also that the formula is symmetric in x₁ ↔ x₂ but the y terms are not, which is why P + Q = Q + P holds while P + (−P) needs its own case.

A single addition costs one modular inversion (the expensive part: here it is done by Fermat exponentiation, a^(p−2)) plus two or three modular multiplications/squarings. Real libraries use projective or Jacobian coordinates to defer the inversion, trading it for extra multiplications, because inversions are roughly a hundred times more expensive than multiplications.

4. Why ∞ is the identity, and when it appears

The point at infinity is not a coordinate pair and cannot be serialized as a public key — the standard encodings simply have no room for it. It exists as the answer to "what is the third intersection when the line is vertical", and it behaves exactly like zero in ordinary arithmetic:

Three situations produce it, and this page shows whether the result is ∞ explicitly:

• Adding a point to its own negation. P + (−P) = ∞. You can see this yourself: add the demo public key to its negation — the two inputs share an x coordinate and differ only in the 02/03 prefix.
• Doubling a point with y = 0. The tangent is vertical, so the result is ∞. On secp256k1 no such point exists: a point with y = 0 would satisfy 2P = ∞, i.e. it would be an element of order 2, and a group of prime order n (an odd prime) has no elements of order 2. The branch is in the code for safety, not because you can reach it here.
• Multiplying the generator by a multiple of n. n · G = ∞ by definition of the order, and therefore (n+1) · G = G. This is exactly why private keys are restricted to [1, n−1]: a "private key" of n+1 would be a legal-looking 32-byte number that silently behaves like 1.

5. Cofactor 1, cyclicity, and why every public key is a multiple of G

The number of points on the curve is h · n with h the cofactor. For secp256k1, h = 1, so the group order is n, and n is prime. This has several very convenient consequences:

• No small subgroups. A group of prime order has exactly two subgroups: {∞} and the whole group. Curves with a cofactor above 1 (Curve25519, for instance, has h = 8) contain small-order points, and an attacker who can force a victim to operate on one of them can learn bits of a secret through invalid-curve attacks. Implementations must then multiply by the cofactor or blacklist those points. Here there is nothing to clear.
• The group is cyclic of order n. Every non-identity point has order exactly n (its order divides n and is not 1). So any point other than ∞ generates the entire group — G is not special mathematically, it is merely the publicly agreed starting point.
• Every public key is some k · G, with k ∈ [1, n−1], and that k is unique. Existence follows from cyclicity; uniqueness from the fact that k₁·G = k₂·G implies (k₁−k₂)·G = ∞, which can only happen when k₁ ≡ k₂ (mod n).
• Scalars distribute. (a + b)·G = a·G + b·G and (a·b)·G = a·(b·G). This is why a BIP32 child key can be computed as a scalar sum, and why "double the point" equals "use twice the scalar" — both are shown in the worked example below.

6. Double-and-add: how k · G is actually computed

There is no closed-form shortcut for scalar multiplication, so implementations iterate the bits of the scalar. The version in this codebase walks the 256 bits from most significant to least:

R = ∞                          # the identity
for bit in bits_of(k):         # 256 iterations for a 256-bit scalar
    R = double(R)              # R = R + R
    if bit == 1:
        R = add(R, G)          # R = R + G
return R                       # R = k · G

The cost is one doubling per bit plus one addition per set bit. For the demo private key 0824c314…171ca the bit census is 256 bits with 116 of them set, so the loop performs 256 doublings and 116 additions — 372 point operations, each of which internally is one inversion plus a few multiplications. Production code uses windowed or fixed-window methods (precomputing G, 2G, 3G, …, 15G and processing four bits at a time) to cut that count by roughly a third, and a Montgomery ladder when the scalar must stay secret.

7. Timing, side channels and what "constant time" means here

The pseudocode above is a security hazard if the scalar is a real private key, because its control flow depends on the secret: a scalar bit of 0 skips the addition, a bit of 1 performs it. Any observer who can measure how long a signature or a derivation takes, or watch the power drawn by the chip, can recover the scalar bit by bit. This is not theoretical: timing attacks on naive ECDSA implementations have recovered keys across a network.

Constant time means the sequence of executed operations and memory accesses does not depend on secret values — only the data does. Concretely, implementations achieve it by always doing both the doubling and the addition and then selecting the right result arithmetically; by using unified addition formulas with no special cases; by scalar blinding (computing (k + r·n)·G for a random r, which gives the same point but a different bit pattern); and by point blinding. libsecp256k1 combines several of these and is written specifically to avoid secret-dependent branches.

8. Worked example: doubling G

The most-cited sanity check on any secp256k1 implementation is 2G. Using the tangent formula with the real constants above, this page computes:

Two more checks you can reproduce with the form above, both of which exercise the identities from §5:

• Scalar multiplication and doubling agree: in mul mode with the demo private key you get k·G = 02ff812e…8c67ee80, which is exactly the demo public key. Doubling that point in double mode produces a compressed result that starts 028c65af…, and the (2k mod n) · G cross-check row in the results panel returns precisely the same value — the identity 2·(k·G) = (2k)·G made visible. (The panel prints both values in full, so you can compare them digit by digit.)
• Inverses cancel: add mode with 02ff812e…8c67ee80 and 03ff812e…8c67ee80 returns the point at infinity and no serialization at all, because ∞ has no coordinates.

9. Common mistakes

• Feeding a scalar to a point parser. A 64-hex-digit string is a legal scalar and a legal x-only public key. This page decides which one you meant from the mode, and the hint under each field says so. Getting it wrong gives a valid-looking but unrelated result.
• Skipping the on-curve check. Accepting an arbitrary (x, y) as a point is how invalid-curve attacks start. Every parse here verifies y² ≡ x³ + 7 (mod p) and throws a readable error otherwise — try a deliberately off-curve uncompressed key and watch the red box.
• Assuming small scalars are safe. 1·G = G publicly. Scalars like 1, 2, 3, 0x1234 are trivially searchable; that is why real key generation uses 256 bits of entropy, not "a number I like".
• Expecting to serialize ∞. There is no prefix for it. Code that does not check for it will either crash or emit a bogus 04 key.
• Confusing this with ECDSA. Signing needs nonces and modular arithmetic over n; this page only covers the group law, which is the arithmetic layer underneath.

10. Quick reference