The first constant we care about is p; TierNolan already explained that one. It's the largest prime that satisfies: p = 2^256 - 2^32 - t where t < 1024
But why 1024? What does 1024 have to do with the EC math?
Why the largest prime for t<1024, not e.g. the smallest prime for t>1024?
This explanation, instead of answering questions, only creates more.
Not really, the reasons here are well understood by anyone working on this stuff in detail.
The number is a
generalized mersenne prime. The reason for this is that our we are doing calculations in this field so when we multiply we must take the result mod p where p is the size of the field. If p is a freely chosen prime to compute the mod we must divide which is hideously complex. Instead, if P has special form, we can break the larger value at the word level into small fragments and compute the mod p as some sum of them with negations. The performance impact is enormous.
This is just an extension of how it's easier to compute x%16, which can be computed as x
&15, then it is to compute x%13.
The reason to use largest prime is just to have the largest field size for one admitting the optimization.
The same reasonable sounding criteria has been used to select primes for many different curves, so it's unlikely that a bad prime was selected and then a complicated explanation was found. The explanation gives a real performance improvement, makes sense, and then was used many times to pick many numbers.
Likewise the efficient endomorphism selection of the a and curve formula permits using the
GLV method to speed up point multiplies. This optimization is used by Pieter's
libsecp256k1 to make ECDSA verification on x86_64 something like 6x faster than OpenSSL for our curve.
Maybe it turns out that these selections for performance also turn out to select for some weakness. No one knows what unknown math will bring. But the performance benefits are not small, so you don't have to hypothize some rigged process to explain this stuff. (And certainly ECDSA performance is very important to our applications.) As a side effect, this eliminates all random parameters, save the generator. So thats a great relief for anyone concerned that our parameters were mysterious and could have been rigged via non-public selection.
I have no blinking idea where the generator comes from, but also can't come up with _any_ way it could be an attack even if I assume that our curve has a weakness of every form which I've heard of for discrete log on an abelian variety. The generator is generally irrelevant. You might be able to pick one which permits faster multiplication under some specific multiplication scheme, but I asked Pieter about that and he seemed to believe that it would take a exponentially hard search, so was unlikely to be very useful... I've only bothered expending time thinking about it because I can't figure out why, due to the irrelevance of its specific value, they didn't pick one with a more compact binary representation, and because its the only parameter thats unexplained though it is the only one which there is no real reason to care about.
This isn't to say that the curve selection couldn't be better: Ed25519 is still somewhat faster than Pieter's code. Our parameters pick a curve who's quadratic twist is not of prime order, which means that some optimizations (e.g. the ones used in Ed25519) are not available, and it also means that a single bit error during a multiply (e.g. for doing ECDH) could basically leak the private key. (Basically an off by one in the x coordinate instead gives a value on the twist, and because the twist's order is factorable, the discrete log problem can be solved on it with complexity related to its largest factor, which is only about 2^50). But the ideas behind making curves for high performance which are better in these respects all came after these parameters were selected.
Hopefully the more cryptography enters into the public eye, cryptographers will be more apt to write papers that are digestible by a wider audience. Is it possible to simply avoid getting into the situations described by the paper? Or would doing so effectively reduce the security by the same amount? 
