We would not want to use these functions internally because we rely on
USE_EXTERNAL_DEFAULT_CALLBACKS to provide the callbacks at link time,
see f7a4a7ef57. Moreover, we would not
want to export the functions either.
Some new fuzz tests I was writing ended up failing because two
nodes came up with different keys because adding public keys and
adding a tweak to a private key and multiplying by the generator
should get the same thing.
Pieter moved some stuff I need into the contrib/ directory which does
not expose anything through the shared lib, so I need to statically
link.
I might also use this to do evil things to expose the SHA256 code
in libsecp, but not for now ;).
This should be a major version number since I changed public constants
in the ffi module. I'm not doing so as the invariant "will the constants
be meaningful to the underlying library" has not changed.
In general this library's version numbers do not map well to the
underlying library, which is as-yet not versioned at all, so users
need to always be running "the lastest" rust-secp256k1 anyway, and
semantic versioning can't really be used meaninfully. So this is a
bit of a judgement call.
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.
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 :))
Andrew Poelstra
Elichai Turkel
Tim Ruffing
Jonas Nick
François Garillot
Matt Corallo
Pierre Krieger
Roman Zeyde
Dawid Ciężarkiewicz