I didn't mean for both of these to go into the same commit, but given how
small the ECDH code was, and the fact that no commit prior to this one will
compile (as both libsecp256k1 and rustc have changed so much), I'm letting
it slide.
There are a lot of cases in rust-bitcoin where we need a `Secp256k1`
which doesn't need any signing or verification capabilities, only
checking the validity of various objects. We can get away with a bare
context (i.e. no precomputation) which can be cheaply created on demand,
avoiding the need to pass around references to Secp256k1 objects everywhere.
API break because the following functions can now fail (given an insufficiently
capable context) and therefore now return a Result:
Secp256k1::generate_keypair
Secp256k1::sign
Secp256k1::sign_compact
The Rng was only used for key generation, and for BIP32 users not even then;
thus hauling around a Rng is a waste of space in addition to causing a
massive amount of syntactic noise. For example rust-bitcoin almost always
uses `()` as the Rng; having `Secp256k1` default to a `Secp256k1<Fortuna>`
then means even more syntactic noise, rather than less.
Now key generation functions take a Rng as a parameter, and the rest can
forget about having a Rng. This also means that the Secp256k1 context
never needs a mutable reference and can be easily put into an Arc if so
desired.
This comes with a couple bugfixes and the following API changes:
- Secp256k1::sign and ::sign_compact no longer return Result;
it is impossible to trigger their failure modes with safe
code since the `Message` and `SecretKey` types validate when
they are created.
- constants::MAX_COMPACT_SIGNATURE_SIZE loses the MAX_; signatures
are always constant size
- the Debug output for everything is now hex-encoded rather than
being a list of base-10 ints. It's just easier to read this way.
kcov v26 now reports 100% test coverage; however, this does not
guarantee that test coverage is actually complete. Patches are
always welcome for improved unit tests.
Now that you can't create secret keys by directly passing a Rng to
`SecretKey::new`, we need a way to allow user-chosed randomness.
We add it to the `Secp256k1`.
Rather than have global initialization functions, which required
expensive synchronization on the part of the Rust library,
libsecp256k1 now carries its context in thread-local data which
must be passed to every function.
What this means for the rust-secp256k1 API is:
- Most functions on `PublicKey` and `SecretKey` now require a
`Secp256k1` to be given to them.
- `Secp256k1::verify` and `::verify_raw` now take a `&self`
- `SecretKey::new` now takes a `Secp256k1` rather than a Rng; a
future commit will allow specifying the Rng in the `Secp256k1`
so that functionality is not lost.
- The FFI functions have all changed to take a context argument
- `secp256k1::init()` is gone, as is the dependency on std::sync
- There is a `ffi::Context` type which must be handled carefully
by anyone using it directly (hopefully nobody :))
Matt Quinn
Andrew Poelstra