Non-randomness of secp256k1 domain parameter generation: a cryptanalytic study of the nature of the G-point and the modular structure of the Gₓ coordinate

21.07.2026

Scientific and analytical review Section: applied cryptography and cryptanalysis of elliptic curves
Date of preparation: July 2026

Abstract. This paper examines the cryptanalytic thesis that the parameters of the secp256k1 elliptic curve used in the Bitcoin protocol are not the product of arbitrary pseudo-random selection, but rather exhibit characteristics of a deterministic, “nothing-up-my-sleeve” (NUMS) construction. It is shown that the predictability and mathematical simplicity of the origin of the parameters (prime field p, curve coefficients a=0, b=7, generator point G) reduce the likelihood of hidden weaknesses and facilitate independent verification. A separate section discusses a methodological technique illustrating how the Gₓ coordinate can be represented as a unique solution to a system of congruences modulo several pairwise primes (the Chinese Remainder Theorem, CRT) using practical examples in Magma, SageMath, Python, and PARI/GP. The numerical value of probability ~1/2^397, cited in popularizing sources as an estimate of “non-randomness”, is separately critically assessed, and its heuristic, not strictly proven status is designated.

1. Introduction and statement of the cryptanalytic problem

The security of any elliptic curve system (ECC) fundamentally depends on the origin of the domain parameters: the prime p defining the finite field, the curve coefficients a and b, the group order n, and the coordinates of the base point G = (Gₓ, G_y). If even one of these parameters was not chosen randomly, but rather tweaked by a developer with knowledge of some secret construction, a “backdoor” could theoretically exist that allows for an efficient solution to the discrete logarithm problem for a specific curve while leaving it secure to all other observers.

This issue gained widespread attention following Edward Snowden’s revelations about a built-in flaw in the Dual_EC_DRBG generator, developed with the assistance of the NSA [web:24] . Since then, the cryptographic community has paid increased attention to the origins of the parameters of the standard curves, in particular the comparison between the pseudorandomly generated P-256 curve (secp256r1) and the deterministically constructed Kobitz curve secp256k1 used by Bitcoin.

A historical example. In 2013–2014, following the publication of Shumov and Ferguson (CRYPTO 2007) on a structural anomaly in Dual_EC_DRBG, the community began retrospectively checking the origins of the constants in the NIST SP 800-90A standard; it was discovered that RSA Security had received $10 million from the NSA for using this generator by default in its BSAFE library 

[web:24] . This case became a textbook argument in favor of requiring “transparent,” verifiable origins for cryptographic constants.

2. secp256k1 domain parameters: origin and determinism

The SEC 2: Recommended Elliptic Curve Domain Parameters (SECG) specification describes secp256k1 as a Kobitz curve over the prime field [web:11] . The key parameters are:

ParameterMeaning / Origin
p2²⁵⁶ − 2³² − 977 is the largest prime number of this type that allows the construction of a Kobitz curve of prime order [web:2]
a0 – deliberately chosen as a “nothing-up-my-sleeve” value [web:1]
b7 is the smallest positive b that ensures a prime order curve for given p and a [web:1][web:2]
Gₓ0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
G_y0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
n (order G)0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
Cofactor h1 (the order of the group is a prime number)

The key difference from “pseudo-random” Weierstrass curves (e.g., secp256r1/P-256, whose coefficients are derived by hashing an opaque seed) is that the parameters a and b of the secp256k1 curve are determined by a deterministic algebraic criterion—minimality—rather than by hashing an arbitrary seed [web:1][web:20] . This dramatically reduces the degree of freedom an attacker could exploit to surreptitiously introduce a weakness.

2.1. The G-spot and its design

A Bitcoin StackExchange researcher has demonstrated a distinctive technical feature: when multiplying G by the inverse of 2 modulo order n, the resulting X-coordinate is anomalously small, suggesting a likely construction scheme—first choosing a “simple” X-coordinate of the half-point, then finding the corresponding Y-coordinate, and doubling the result to obtain the final G [web:7] . This procedure is typical of a deterministic, reproducible generator construction, rather than an arbitrary random selection.

A historical parallel. A similar “reverse-engineering” of domain parameters was performed by the community for P-256: the 1998 draft of the X9.62 standard contains a procedure for generating coefficients based on a seed value, but the origin of the specific seed for P-256 remains undocumented, which has led to years of speculation about a built-in NSA “backdoor” 

[web:20][web:24] . Unlike P-256, the secp256k1 design does not require trust in an opaque seed.

3. Cryptographers’ Opinions: Arguments for and Against “Non-Randomness” as a Security Feature

Cryptographer Tatsuaki Okamoto (NTT Research) has publicly noted that Satoshi Nakamoto’s choice of the secp256k1 Kobitz curve over the standard secp256r1 could be explained by two alternative hypotheses: either the increased computational efficiency of scalar multiplication, or the desire to avoid a potential hidden “backdoor” that a pseudo-randomly generated curve could theoretically possess [web:22][web:23] . Bitcoin Core developer Wladimir van der Laan confirmed that there is no documented explanation for Satoshi’s choice, but noted that “in retrospect, it looks like a good decision” [web:22] .

Thus, the cryptanalytic consensus is formulated as follows: the determinism and mathematical transparency of the construction of the Kobitz curve parameters (in contrast to the NIST hash seed scheme) do not prove security strictly mathematically, but significantly facilitate independent audit and minimize the space of possible manipulations by the developer of the standard [web:1][web:9] .

4. Modular (CRT) representation of the Gₓ coordinate: methodology and demonstration

A separate class of cryptanalytic illustrations demonstrates that an arbitrary large integer, including the coordinate Gₓ, can be uniquely reconstructed from its remainders when divided by a set of pairwise prime moduli, if the product of these moduli exceeds the original number. This is a direct consequence of the Chinese Remainder Theorem (CRT): for pairwise coprime m₁,…,m_k and a product M = m₁ m₂… m_k, any integer 0 ≤ X < M is uniquely determined by the set of remainders (X mod m₁, …, X mod m_k).

Methodological note. The claim that the probability of a random coincidence of Gₓ with a solution to such a CRT system is ~1/2^397 is not an established and peer-reviewed mathematical result in the open cryptography literature (SECG, NIST, academic publications on ECC). Such an estimate typically appears in popular or informal discussions as a way to emphasize the “structure” of a number, but every 256-bit number is trivially representable via a CRT factorization over any set of moduli whose product exceeds its magnitude—this in itself is not statistical proof of “non-randomness.” Below is a technical demonstration of the method on a real value of Gₓ, accompanied by a critical assessment of the interpretation.

4.1 Numerical data

Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 
   = 55066263022277343669578718895168534326250603453777594175500187360389116729240 
p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F 
   = 2^256 - 2^32 - 977

4.2. Python example

from sympy import nextprime 
from sympy.ntheory.modular import crt 

Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 

# matching four pairwise prime modules (64-bit) for demonstration 
primes = [] 
x = 2**64 
while len(primes) < 4: 
    x = nextprime(x) 
    primes.append(x) 
    x += 10**9 

remainders = [Gx % pr for pr in primes] 
result, modulus = crt(primes, remainders) 

print("Modules:", primes) 
print("Remainders:", remainders) 
print("Recovered X == Gx:", result == Gx) # -> True

4.3. Example on SageMath

Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 

primes = [next_prime(2^64 + i*10^9) for i in range(4)] 
remainders = [Gx % pr for pr in primes] 

X = CRT_list(remainders, primes) 
print(X == Gx) # True

4.4. Example on Magma

Gx := 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798; 
primes := [NextPrime(2^64), NextPrime(2^64 + 10^9), 
           NextPrime(2^64 + 2*10^9), NextPrime(2^64 + 3*10^9)]; 
remainders := [Gx mod m : m in primes]; 
X := CRT(remainders, primes); 
print X eq Gx; // true

4.5. Example on PARI/GP

Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798; 
p1 = nextprime(2^64); p2 = nextprime(p1+10^9); 
p3 = nextprime(p2+10^9); p4 = nextprime(p3+10^9); 
r = [Gx % p1, Gx % p2, Gx % p3, Gx % p4]; 
X = chinese([Mod(r[1],p1), Mod(r[2],p2), Mod(r[3],p3), Mod(r[4],p4)]); 
lift(X) == Gx 
\\ -> 1 (true)

4.6. Results of computational verification

A practical run of the given Python example in a computing environment yielded the following results: four 64-bit prime moduli with a product greater than p (a total bit size of 257 bits versus 255 bits for Gₓ) correctly reconstruct the original value of Gₓ using the CRT—a match confirmed programmatically. This demonstrates the mathematical mechanics of the method, but it is important to understand that such a reconstruction is possible for any integer with an appropriate choice of moduli, and does not in itself serve as proof of the developer’s “intent” or an inherent weakness.

A similar historical example from cryptanalysis. In the BIP-341 (Taproot) specification, a “nothing-up-my-sleeve” point (NUMS point) is used to avoid hidden backdoors. It is deterministically derived from the hash of the string description, rather than being chosen 

[web:5] . This illustrates a general cryptanalytic principle: a transparent, reproducible parameter generation procedure is preferable to an opaque choice, even if both are technically verifiable post-factum.

5. Estimating the Probability of ~1/2^397: A Critical Analysis

The claimed probability of a “random match” of ~1/2^397 is numerically greater than the entropy of the Gₓ coordinate itself (255–256 bits), indicating that a direct interpretation of such an estimate as “the probability of a random match of a single 256-bit value” is incorrect. Technically, such estimates in independent sources typically combine several independent structural matches (e.g., a match of residues in several moduli simultaneously with other statistical features—low values ​​after multiplication by the inverse, as shown in Section 2.1 [web:7] ), but the formal derivation of such a combined value is not documented in the peer-reviewed literature on ECC. The cryptanalytically correct position is to regard such numerical estimates as heuristics in need of independent mathematical verification, rather than as a proven fact.

6. Conclusion: The Importance of Parameter Transparency for Security Auditing

The combination of the features considered—the deterministic output of p, the deliberate choice of a=0 and minimal b=7, and the reproducible (though not explicitly documented by Satoshi) scheme for constructing G—creates a significantly narrower space of “degrees of freedom” compared to hash-seeded parameter generation schemes (as in secp256r1). It is this transparency and simplicity of the origin of the parameters, rather than a single numerical probability metric, that is the key cryptanalytic argument in favor of secp256k1 being more difficult to exploit for covertly embedding weaknesses and easier to independently audit by the entire cryptographic community [web:1][web:9][web:22] .Prepared based on an analysis of the SECG technical documentation (SEC 2 v2), materials from the Bitcoin StackExchange, Crypto StackExchange, and public comments from cryptographers (T. Okamoto, W. van der Laan). Computational examples were verified by running the code on the actual Gₓ coordinate of the secp256k1 curve.