Cfrgtkky

In Bitcoin's elliptic curve (secp256k1),

the prime

p = 2^256 - 2^32 - 2^9 -2^8 - 2^7 - 2^6 - 2^4 - 1

the generator point

Gx = 

0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798



Gy = 

0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

and the order of the group generated by G

n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

are predefined.

What is the reasoning behind this? Why are these values more secure or efficient than any other ones?

Secp256k1 was designed to be a 256-bit size elliptic curve without cofactor and admitting an efficient endomorphism for optimization purposes. The choices of the relevant parameters are derived from these criteria.

P is selected allow a more efficient implementation on general purpose computers. See Solinas' paper on Generalized Mersenne Numbers. We don't know the exact search procedure Certicom used to select P, but it is the first prime you get if you search 2^256 - 2^32 - (1024 - x).

We know, however, that this may not be the exact procedure they would have needed because the presence of the endomorpism requires a cube root of unity. See this answer on crypto stack exchange. But they could have searched this way and got lucky.

The generator could be just any point on the curve and it is trivial to prove that the choice of generator is irrelevant to the security of any scheme that doesn't involve coercing values into curvepoints, and pretty narrowly relevant otherwise.

We haven't been able to uncover how G was selected, but I did discover that it a value that was likely obtained by doubling a point with a very small (166 bit) x coordinate. The same value was used in several other ECC standards. (I wouldn't be surprised if it was the hash of someone's name of something silly like that, but it seems that this trivia might have followed Scott Vanstone to his grave).

Since the curve order is prime the order of G isn't a parameter so much as the result of the selection of the field and the curve equation. 'b' in the curve equation being 7 was almost certainly just because it was the first value that gives a secure curve. 'a' being 0 is a necessary condition for the endomorphism.

You might also find this old thread on bitcointalk interesting.

A very short layman's answer (not mathematically correct) is the normalization of the the private key needs to be a very large prime number less than 2^256-1 to ensure the cyclic modulo operation does not easily repeat predictably to compute the associated public key. If someone was able to discover a larger prime number than p = 2^256 - 2^32 - 2^9 -2^8 - 2^7 - 2^6 - 2^4 - 1 and less than 2^256-1, such a number could have been used for cyclic normalization. Additionally, a good pseudo random number generator heuristic is to initially seed them with very large prime numbers.

That is probably for others here to answer but I will give it a shot.

We are looking for an elliptic curve which has a cyclic subgroup with a high order (but not higher than 2^256 as we want to work with 32byte private keys and the private keys are the orders of the elements with respect to the generator point) this particular elliptic curve over that prime field seems to fulfill these properties.

The order of the subgroup basically defines the difficulty for the discret logarithm. If the subgroup for example was of an order so small that one could store all group ements on a computer one could just compute it and break any public key coming from that group.

As for the generator point. I believe this is an arbitrary choice. Since the group is cyclic (and afaik of prime order) any other element (unless the neutral one) could have served as the generator. However we need to agree on a fixed generator point for ecdsa to have the same results every time we run the algorithms. Therefor one element was chosen.

I am not sure if there is more theory as to why this particular configuration seems preferable.