As Pieter already described in his reply it isn’t identified why the multiplicative inverse of two of the generator level of secp256k1 is such a brief (166 bit) quantity.
However curiously all prime order koblitz curves of the SEC 2 household (secp160k1, secp192k1, secp224k1, secp256k1) share this uncommon property.
Furthermore all these quick x-coordinates of those supply factors share a big quantity of their bits (152 bits for all these x-values are the identical):
secp160k1: 0x4_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_2
secp192k1: 0x554123b7_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_6
secp224k1: 0x3b7_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_3
secp256k1: 0x3b7_8ce563f89a0ed9414f5aa28ad0d96d6795f9c6_3
(I inserted the _ to visualise the equivalent half within the numbers.)
So possibly again within the 90s somebody at Certicom hashed one thing right into a 160 bit hash after which determined to exchange the primary and the final 4 bits per curve (and added a prefix worth for 3 of them)?
Who is aware of? It is an fascinating thriller. 🙂
I can extremely advocate this quick discuss from Nadia Heninger about this subject:
https://www.youtube.com/watch?v=NGLR2N4EK58
Edit:
To confirm this your self in Sage (instance for secp192k1, merely change curve parameters for the opposite secp…k1 curves):
# outline 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 level G
sage: G = secp192k1.level(('0xdb4ff10ec057e9ae26b07d0280b7f4341da5d1b1eae06c7d' , '0x9b2f2f6d9c5628a7844163d015be86344082aa88d95e2f9d'))
# multiply with multiplicative inverse of two:
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'