<p>As Pieter already described in <a href="https://bitcoin.stackexchange.com/a/113122/109728">his answer</a> it is not known why the multiplicative inverse of 2 of the generator point of <code>secp256k1</code> is such a short (166 bit) number.</p>
<p>But interestingly all prime order koblitz curves of the SEC 2 family (<code>secp160k1</code>, <code>secp192k1</code>, <code>secp224k1</code>, <code>secp256k1</code>) share this unusual property.</p>
<p>Moreover all these short x-coordinates of these source points share a significant amount of their bits (152 bits for all these x-values are the same):</p>
<pre><code>secp160k1:         0x4_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_2
secp192k1:  0x554123b7_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_6
secp224k1:       0x3b7_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_3
secp256k1:       0x3b7_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_3
</code></pre>
<p>(I inserted the <code>_</code> to visualize the identical part in the numbers.)</p>
<p>So maybe back in the 90s someone at Certicom hashed something into a 160 bit hash and then decided to replace the first and the last 4 bits per curve (and added a prefix value for 3 of them)?</p>
<p>Who knows? It's an interesting mystery. :)</p>
<p>I can highly recommend this short talk from Nadia Heninger about this topic:
<a href="https://www.youtube.com/watch?v=NGLR2N4EK58" rel="noreferrer">https://www.youtube.com/watch?v=NGLR2N4EK58</a></p>
<p><strong><em>Edit</em>:</strong></p>
<p>To verify this yourself in Sage (<em>example for <code>secp192k1</code>, simply change curve parameters for the other secp...k1 curves</em>):</p>
<pre><code># define the curve from parameters
sage: prime_p = ZZ('0xfffffffffffffffffffffffffffffffffffffffeffffee37')
sage: a = 0
sage: b = 3

sage: secp192k1 = EllipticCurve( GF(prime_p), [a, b] )
sage: order_n = secp192k1.order()  # get order of the curve

# generator point G
sage: G = secp192k1.point(('0xdb4ff10ec057e9ae26b07d0280b7f4341da5d1b1eae06c7d' , '0x9b2f2f6d9c5628a7844163d015be86344082aa88d95e2f9d'))

# multiply with multiplicative inverse of 2:
sage: Point_half_G_mod_n = G *  ZZ( 1 / GF(order_n)(2) )

# print coordinates in hex:
sage: 'x: %x, y: %x'  %( Point_half_G_mod_n.xy() )
'x: 554123b78ce563f89a0ed9414f5aa28ad0d96d6795f9c66, y: 90755fc93ea4b13027fc6c8f337d92c6d00090fad0e8b2c6'
</code></pre>

CC BY-SA 4.0
2022-04-28T06:57:06.320Z
2022-04-28T16:46:56.213Z
2022-04-28T16:46:56.213Z
Johannes Zweng
<p>We don't know. The <code>secp256k1</code> curve (and the corresponding generator) was defined and standardized by people at Certicom. I know people have inquired about its origins, but it appears those involved are simply not around anymore.</p>
<p>There is however an unsual property that may give a hint about how it was constructed. If the point is multiplied by the multiplicative inverse of 2 (so effectively undoing a doubling operation), one gets the point with X coordinate 0x3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63, an unfathomably small number (only 166 bits in size). Perhaps the generator was constructed by hashing some simple input, feeding it through a 160-bit hash function, prefixing it with 0x3b, constructing the point with the result as X coordinate, and then doubling it.</p>
<p>That said, it is believed that the choice of generator is irrelevant for security properties of schemes that only use one generator (like ECDSA, BIP340 Schnorr signatures, ECDH, ...).</p>

CC BY-SA 4.0
2022-04-02T17:02:00.620Z
2024-11-24T03:16:33.203Z
2024-11-24T03:16:33.203Z
Pieter Wuille
<p>The generator point G in the secp256k1 curve used in Bitcoin is a known constant:</p>
<pre><code>Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
</code></pre>
<p>How was this point determined or chosen? I understand it needs to be a point with large order (which is the case for G) but other than that, was it chosen randomly or is it somehow derived deterministically?</p>

CC BY-SA 4.0
2022-04-27T11:32:44.923Z
The group it generates is cyclic. Any element of that group could have been chosen.
Rene Pickhardt
CC BY-SA 4.0
2022-04-28T14:15:03.727Z
This is a duplicate of https://bitcoin.stackexchange.com/questions/58784/how-were-the-secp256k1-base-point-coordinates-decided, and the most exhaustive answers can be found here: https://crypto.stackexchange.com/questions/60420/what-does-the-special-form-of-the-base-point-of-secp256k1-allow
real-or-random
<cryptography><secp256k1>
How is the generator point G chosen in the secp256k1 curve used in Bitcoin?
RocketNuts
# How is the generator point G chosen in the secp256k1 curve used in Bitcoin?

(Asked by: username_0 on 2022-04-02)

The generator point G in the secp256k1 curve used in Bitcoin is a known constant:

```
Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8

```

How was this point determined or chosen? I understand it needs to be a point with large order (which is the case for G) but other than that, was it chosen randomly or is it somehow derived deterministically?

**Tags:** cryptography, secp256k1

> **Comments:**
> **username_1**: The group it generates is cyclic. Any element of that group could have been chosen.  
> **username_2**: This is a duplicate of https://bitcoin.stackexchange.com/questions/58784/how-were-the-secp256k1-base-point-coordinates-decided, and the most exhaustive answers can be found here: https://crypto.stackexchange.com/questions/60420/what-does-the-special-form-of-the-base-point-of-secp256k1-allow  

---

## 2 answers

### Answer by username_4 on 2022-04-02. Score: 28 | Accepted answer

We don't know. The `secp256k1` curve (and the corresponding generator) was defined and standardized by people at Certicom. I know people have inquired about its origins, but it appears those involved are simply not around anymore.

There is however an unsual property that may give a hint about how it was constructed. If the point is multiplied by the multiplicative inverse of 2 (so effectively undoing a doubling operation), one gets the point with X coordinate 0x3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63, an unfathomably small number (only 166 bits in size). Perhaps the generator was constructed by hashing some simple input, feeding it through a 160-bit hash function, prefixing it with 0x3b, constructing the point with the result as X coordinate, and then doubling it.

That said, it is believed that the choice of generator is irrelevant for security properties of schemes that only use one generator (like ECDSA, BIP340 Schnorr signatures, ECDH, ...).


---

### Answer by username_3 on 2022-04-28. Score: 12

As username_4 already described in [his answer](https://bitcoin.stackexchange.com/a/113122/109728) it is not known why the multiplicative inverse of 2 of the generator point of `secp256k1` is such a short (166 bit) number.

But interestingly all prime order koblitz curves of the SEC 2 family (`secp160k1`, `secp192k1`, `secp224k1`, `secp256k1`) share this unusual property.

Moreover all these short x-coordinates of these source points share a significant amount of their bits (152 bits for all these x-values are the same):

```
secp160k1:         0x4_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_2
secp192k1:  0x554123b7_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_6
secp224k1:       0x3b7_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_3
secp256k1:       0x3b7_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_3

```

(I inserted the `_` to visualize the identical part in the numbers.)

So maybe back in the 90s someone at Certicom hashed something into a 160 bit hash and then decided to replace the first and the last 4 bits per curve (and added a prefix value for 3 of them)?

Who knows? It's an interesting mystery. :)

I can highly recommend this short talk from Nadia Heninger about this topic:
<https://www.youtube.com/watch?v=NGLR2N4EK58>

***Edit*:**

To verify this yourself in Sage (*example for `secp192k1`, simply change curve parameters for the other secp...k1 curves*):

```
# define the curve from parameters
sage: prime_p = ZZ('0xfffffffffffffffffffffffffffffffffffffffeffffee37')
sage: a = 0
sage: b = 3

sage: secp192k1 = EllipticCurve( GF(prime_p), [a, b] )
sage: order_n = secp192k1.order()  # get order of the curve

# generator point G
sage: G = secp192k1.point(('0xdb4ff10ec057e9ae26b07d0280b7f4341da5d1b1eae06c7d' , '0x9b2f2f6d9c5628a7844163d015be86344082aa88d95e2f9d'))

# multiply with multiplicative inverse of 2:
sage: Point_half_G_mod_n = G *  ZZ( 1 / GF(order_n)(2) )

# print coordinates in hex:
sage: 'x: %x, y: %x'  %( Point_half_G_mod_n.xy() )
'x: 554123b78ce563f89a0ed9414f5aa28ad0d96d6795f9c66, y: 90755fc93ea4b13027fc6c8f337d92c6d00090fad0e8b2c6'

```


---

