Native num implementation. #30

A native (and perhaps naive) num implementation would be nice, so libsecp256k1 can be built entirely dependencyless.

The largest challenge is probably a fast modular inverse.

Somewhat related - is the GMP field considered a permanent fixture? I ask because in trying to optimize the point formulas I note that the effects on the GMP field are often opposite to the others. Generally the 32bit and 64bit fields reward reducing the amount of normalization, but GMP tends to reward normalising anything that will be input to more than one mul/sqr (maybe negate too).

There are conceivable, but sometimes fiddly, workarounds, so I'm just wondering if it's important to worry about GMP performance, or perhaps it's value is mainly as a sanity check?

I'd like to keep the GMP field implementation for now, as on 32-bit it significantly outperforms 10x26 (tested on a 64-bit machine, but with a 32-bit binary), and we need GMP anyway for a fast bignum implementation.

However, in terms of priority I think 64-bit performance is more important.

GMP isn't licensed under the MIT/X11 software license. For security it is important to statically link, thus forcing the code under LGPL.

@da2ce7 You're adopting a weird security model where you think static linking improves your security, but I don't care to argue it.

LGPL permits static linking, even with completely proprietary software— you must just provide the objects so that the LGPLed portions can be replaced.

Closing this, as num is fully optional now.