# SECP256K1 implementation in pure Rust
* [Cargo](https://crates.io/crates/libsecp256k1)
* [Documentation](https://docs.rs/libsecp256k1)
SECP256K1 implementation with `no_std` support. Currently we have implementation for:
* Convert a private key to a public key.
* Sign messages.
* Signature verification.
* Public key recovery from signed messages.
* Shared secrets.
## Feature flags
* `std`: If disabled, works in `no_std` environment. Enabled by default.
* `hmac`: Add certain features that requires the HMAC-DRBG. This includes
signing. Enabled by default.
* `static-context`: To speed up computation, the library uses a pre-computed
table context for many `ecmult` operations. This feature flag puts the context
directly as static variables. If disabled, the context must be created from
heap manually. Increases binary size, enabled by default.
* `lazy-static-context`: Instead of storing the pre-computed table context as
static variables, store it as a variable that dynamically allocates the
context in heap via `lazy_static`. It overwrites `static-context`. Impact
bootstrap performance and only available in `std`, disabled by default.
## Development workflow
### Branch
This repository uses `develop` branch for development. Changes are periodically
merged to `master` branch.
### Pull request
All changes (except new releases) are handled through pull requests. Please open
your PR against `develop` branch.
### Versioning
`libsecp256k1` follows [Semantic Versioning](https://semver.org/). An unreleased crate
in the repository will have the `-dev` suffix in the end, and we do rolling
releases.
When you make a pull request against this repository, please also update the
affected crates' versions, using the following rules. Note that the rules should
be applied recursively -- if a change modifies any upper crate's dependency
(even just the `Cargo.toml` file), then the upper crate will also need to apply
those rules.
Additionally, if your change is notable, then you should also modify the
corresponding `CHANGELOG.md` file, in the "Unreleased" section.
If the affected crate already has `-dev` suffix:
* If your change is a patch, then you do not have to update any versions.
* If your change introduces a new feature, please check if the local version
already had its minor version bumped, if not, bump it.
* If your change modifies the current interface, please check if the local
version already had its major version bumped, if not, bump it.
If the affected crate does not yet have `-dev` suffix:
* If your change is a patch, then bump the patch version, and add `-dev` suffix.
* If your change introduces a new feature, then bump the minor version, and add
`-dev` suffix.
* If your change modifies the current interface, then bump the major version,
and add `-dev` suffix.
If your pull request introduces a new crate, please set its version to
`1.0.0-dev`.