- Dec 15, 2015
-
-
Andrew Poelstra authored
-
- Nov 19, 2015
-
-
Andrew Poelstra authored
-
- Nov 15, 2015
-
-
Andrew Poelstra authored
-
- Nov 08, 2015
-
-
Andrew Poelstra authored
We had added a necessary include directory to build.rs but not updated the library on crates.io, so dependencies of rust-secp were failing to build. (However, on my local system I had secp installed in /usr/local/include, so I did not notice the problem until Travis pointed it out on a different project!)
-
- Oct 28, 2015
-
-
Andrew Poelstra authored
-
- Oct 26, 2015
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
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 ;).
-
Andrew Poelstra authored
-
- Oct 25, 2015
-
-
Andrew Poelstra authored
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.
-
- Oct 17, 2015
-
-
Andrew Poelstra authored
-
- Oct 14, 2015
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
[BREAKING CHANGE] Make PK::from_secret_key() return a Result; change from_ffi functions to From impls If you try to call PublicKey::from_secret() key with an incapable context it will now return an error. Before it would pass through to the underlying library which would terminate the process, something we strive to never expose. Also change the from_ffi functions on various types to impl's of From to be more Rustic. We cannot change the from_slice functions because they have error returns. Also add a Secp256k1::without_caps() function which creates a capability-less context. I find myself using this in so many places downstream that it seems appropriate.
-
- Oct 13, 2015
-
-
Andrew Poelstra authored
RecoveryId tag i32 should be public to allow library users to access it.
-
- Oct 11, 2015
-
-
Matt Quinn authored
library users the ability to create RecoveryId objects and convert them to i32 equivalents, without allowing users to create invalid ones.
-
Andrew Poelstra authored
RecoverableSignature now supports compact serialization via FFI, with…
-
Matt Quinn authored
-
- Oct 09, 2015
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
- Sep 21, 2015
-
-
Andrew Poelstra authored
-
- Sep 20, 2015
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
- Sep 18, 2015
-
-
Andrew Poelstra authored
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.
-
- Jul 28, 2015
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
- May 04, 2015
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
- May 03, 2015
-
-
Andrew Poelstra authored
This is a new libsecp256k1 function which does additive blinding for nonce generation during signing.
-
- Apr 30, 2015
-
-
Andrew Poelstra authored
-
- Apr 28, 2015
-
-
Andrew Poelstra authored
-
- Apr 16, 2015
-
-
Andrew Poelstra authored
-
- Apr 14, 2015
-
-
Andrew Poelstra authored
This is kinda silly but gets me 100% coverage from kcov
-
Andrew Poelstra authored
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
-
Andrew Poelstra authored
-
- Apr 12, 2015
-
-
Andrew Poelstra authored
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.
-