libsecp256k1 really only barely uses libc at all, and in practice,
things like memcpy/memcmp get optimized into something other than a
libc call. Thus, if we provide simple stub headers, things seem to
work with wasm-pack just fine.
* rust-bitcoin/master:
Fix no-std raw test, after removal of lang items
Fix broken benchmarks
Disable emscripten tests until they work again https://github.com/rust-lang/rust/issues/66916https://github.com/rustwasm/team/issues/291
Add constant of the prime of the curve field.
Simplify callback logic to returning raw coordinates
Removed no longer used dont_replace_c_symbols feature
Fix wrong feature name external-symbols
Fix missing return c_int in NonceFn
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 ;).
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.
rust-secp256k1 was based off of https://github.com/sipa/secp256k1,
which has been inactive nearly as long as this repository (prior to
a couple days ago anyway). The correct repository is
https://github.com/bitcoin/secp256k1
This is a major breaking change to the library for one reason: there
are no longer any Nonce types in the safe interface. The signing functions
do not take a nonce; this is generated internally.
This also means that I was able to drop all my RFC6979 code, since
libsecp256k1 has its own implementation.
If you need to generate your own nonces, you need to create an unsafe
function of type `ffi::NonceFn`, then pass it to the appropriate
functions in the `ffi` module. There is no safe interface for doing
this, deliberately: there is basically no need to directly fiddle
with nonces ever.