In preparation for doing a point release add a changelog entry, bump the
version, and update all the `0_9_0` identifiers in the vendored code.
Done so we can release the wasm-build bug fix.
Prepare for release by doing:
- Add changelog entry to `secp256k1-sys` for the recent version bump ready
for release.
- Bump the version of secp256k1 to 0.28.0
- Add changelog entry to `secp256k1` for the imminent release.
There are zero code changes required to support v.0.13.0 so we elect to
use a range dependency to make the upgrade path for downstream users
more pleasant.
Upgrade the dependency of `hashes` to be either v0.12.0 or v0.13.0
Use v0.13.0 in the recent/minimal lockfiles.
Use the more terse `hashes` by way of the `package` field in the
manifest.
Allows us to remove the ugly feature alias "bitcoin-hashes" ->
"bitcoin_hashes" and removes all the bother with the underscore.
Why did we not think of this 2 years ago?
The `cbor` crate has been unmaintained for several years, and depends on
the ancient `rustc_serialize` crate which (a) doesn't build on WASM, and
(b) doesn't build when we use a minimal-dep Cargo.lock. (The latter is
because cbor specifies rustc_serialize 0.3.0 when it should specify 0.3.1,
but there is nothing we can do to fix that when cbor is unmaintained.)
This changes a hardcoded value in a regression test, but it's because
we're replacing the serialization engine rather than changing our code,
so this is not actually a change.
We are ready to release a new minor version of `secp256k1-sys`, in order
to do so we must make change the symbol names to reflect the new version
as well as the usual changelog and version bump.
In preparation for releasing `secp256k1-sys` v0.8.1 do:
- Rename symbols to from `0_8_0` -> `0_8_1`, done mechanically (search
and replace)
- Add changes log notes (includes changelog entry for 0.8.0)
- Bump `secp256k1-sys` crate version 0.8.0 -> 0.8.1, justified because
we have added a new public function.
`libsecp256k1` v0.2.0 was just released.
Update the vendored code using
`./vendor-libsecp.sh depend 0_8_0 21ffe4b`
```
git show 21ffe4b
commit 21ffe4b22a9683cf24ae0763359e401d1284cc7a (tag: v0.2.0)
Merge: 8c949f5 e025ccd
Author: Pieter Wuille <pieter@wuille.net>
Date: Mon Dec 12 17:00:52 2022 -0500
Merge bitcoin-core/secp256k1#1055: Prepare initial release
e025ccdf7473702a76bb13d763dc096548ffefba release: prepare for initial release 0.2.0 (Jonas Nick)
6d1784a2e2c1c5a8d89ffb08a7f76fa15e84fff5 build: add missing files to EXTRA_DIST (Jonas Nick)
13bf1b6b324f2ed1c1fb4c8d17a4febd3556839e changelog: make order of change types match keepachangelog.com (Jonas Nick)
b1f992a552785395d2e60b10862626fd11f66f84 doc: improve release process (Jonas Nick)
ad39e2dc417f85c1577a6a6a9c519f5c60453def build: change package version to 0.1.0-dev (Jonas Nick)
90618e9263ebc2a0d73d487d6d94fd3af96b973c doc: move CHANGELOG from doc/ to root directory (Jonas Nick)
Pull request description:
Based on #964
ACKs for top commit:
sipa:
ACK e025ccdf7473702a76bb13d763dc096548ffefba
Tree-SHA512: b9ab71d7362537d383a32b5e321ef44069f00e3e92340375bcd662267bc5a60c2bad60222998e6602cfac24ad65efb23d772eac37c86065036b90ef090b54c49
```
Requires a new version of `secp256k1-sys`, use v0.8.0
- Update the `secp256k1-sys` manifest (including links field)
- Update symbols to use 0_8_0
- Add a changelog entry
- depend on the new version in `secp256k1`
Which in turn requires a new version of `secp256k1`, use v0.26.0
We are ready to release a new minor version of `secp256k1-sys`, in order
to do so we must make change the symbol names to reflect the new version
as well as the usual changelog and version bump.
In preparation for releasing `secp256k1-sys` v0.7.0 do:
- Rename symbols to from `0_6_1` -> `0_7_0`, done mechanically (search
and replace)
- Add changes log notes
- Bump `secp256k1-sys` crate version 0.6.1 -> 0.7.0, justified because
we have added new public methods to various types (e.g.,
`PublicKey::cmp_fast_unstable`)
Currently we have a few problems with our feature gating, attempt to
audit all feature gating and fix it by doing:
1. Do not enable features on optional dependencies (`rand` and
`bitcoin-hashes`) in dev-dependencies, doing so hides broken feature
gating in unit tests.
2. Do not use unnecessary feature combinations when one feature enables
another e.g. `any(feature = "std", feature = "alloc")`.
3. Enable "std" from "rand-std" and "bitcoin-std" (and fix features
gating as for point 2).
4. Clean up code around `rand::thread_rng`, this is part of this patch
because `thread_rng` requires the "rand-std" feature.
5. Clean up CI test script to test each feature individually now that
"rand-std" and "bitcoin-hashes-std" enable "std".
Currently we have a feature `bitcoin-hashes-std` and a dependency
`bitcoin_hashes`, this means one has to think about and change the `_`
and `-` when coding. The underscore in `bitcoin_hashes` is an artifact
of days gone by and we cannot fix it but we can cover it up and make our
lives easier, especially now we have `bitcoin-hashes-std`.
Improve feature usage of the `bitcoin_hashes` library by:
- Add a feature `bitcoin-hashes` that enables `bitcoin_hashes`.
- Use the new feature in all feature gated code
- Use `bitcoin-hashes-std` in feature gated code that includes other
`std` features (e.g. `rand-std`)
The manifest has two cases of leading whitespace, doesn't obviously mean
anything, remove them.
Whitespace was introduced in commit: `7d3a149ca5064147229db147359638cbcb54acdd`
a431edb86a Create configuration conditional bench (Tobin C. Harding)
2a1c9ab4b8 Remove rand-std feature from unstable (Tobin C. Harding)
ddc108c117 Increase heading size (Tobin C. Harding)
596adff8ba Remove unneeded whitespace (Tobin C. Harding)
Pull request description:
As we did in rust-bitcoin [0] create a configuration conditional `bench`
that we can use to guard bench mark code. This has the benefit of
making our features additive i.e., we can now test with `--all-features`
with a stable toolchain (currently this fails because of our use of the
`test` crate).
Please note, this patch maintains the current behaviour of turning on
the `recovery` and `rand-std` features when benching although I was
unable to ascertain why this is needed.
[0] - https://github.com/rust-bitcoin/rust-bitcoin/pull/1092
ACKs for top commit:
sanket1729:
ACK a431edb86a.
apoelstra:
ACK a431edb86a
Tree-SHA512: 913f5fbe0da08ec649081bf237c1d31cee58dacdac251d6030afabb99d455286c6d1dbdb6b2ac892b5d3c24584933254d1cfeec8e12f531cc420bd9d455a6531
As we did in rust-bitcoin [0] create a configuration conditional `bench`
that we can use to guard bench mark code. This has the benefit of
making our features additive i.e., we can now test with `--all-features`
with a stable toolchain (currently this fails because of our use of the
`test` crate).
[0] - https://github.com/rust-bitcoin/rust-bitcoin/pull/1092
Currently the "unstable" feature (used to guard bench mark code) turns
on the "recovery" and "rand-std" features. The "rand-std" feature is not
needed since it is unused, as can be seen by the following bench runs:
Before applying this patch:
...
test benches::bench_sign_ecdsa ... bench: 35,454 ns/iter (+/- 1,376)
test benches::bench_verify_ecdsa ... bench: 44,578 ns/iter (+/- 1,619)
test benches::generate ... bench: 26,800 ns/iter (+/- 2,352)
test ecdh::benches::bench_ecdh ... bench: 51,195 ns/iter (+/- 1,400)
test ecdsa::recovery::benches::bench_recover ... bench: 50,174 ns/iter (+/- 1,572)
test key::benches::bench_pk_ordering ... bench: 5,748 ns/iter (+/- 492)
test result: ok. 0 passed; 0 failed; 76 ignored; 6 measured; 0 filtered out; finished in 14.52s
After removing "rand-std" feature:
...
test benches::bench_sign_ecdsa ... bench: 35,510 ns/iter (+/- 1,504)
test benches::bench_verify_ecdsa ... bench: 42,483 ns/iter (+/- 5,628)
test benches::generate ... bench: 26,573 ns/iter (+/- 1,333)
test ecdh::benches::bench_ecdh ... bench: 50,846 ns/iter (+/- 3,982)
test ecdsa::recovery::benches::bench_recover ... bench: 50,908 ns/iter (+/- 2,775)
test key::benches::bench_pk_ordering ... bench: 6,002 ns/iter (+/- 463)
test result: ok. 0 passed; 0 failed; 60 ignored; 6 measured; 0 filtered out; finished in 6.52s
We just applied a hot fix to the 0.23.0 released code to fix the
features enabled in `rand` when our "rand-std" feature is enabled. This
requires a bump of the patch version for release.
Bump the version and add a changelog entry.
We recently upgraded the rand dependency and we use it behind code
feature gated on "rand-std". In that code we use `thread_rng` but this
is only available if the "std_rng" feature is turned on, however in
non-dev builds we do not enable this feature, we have a "rand-std"
feature that enables "rand/std", it should also enable "std_rng".
Enable "rand/std_rng" in the "rand-std" feature.
Add a `tests` directory. Add `serde` tests for the recently added fixed
width binary serialization code.
Please note, serialization is only fixed width when serialized with
the `bincode` crate.
Currently we use 'no default features' for the `bitcoin_hashes`
dependency. Doing so means that if users want the `std` feature they
need to explicitly add a `bitcoin_hashes` dependency even though we
re-export `bitcoin_hashes` as `hashes`. This means that in the common
case the re-export is pointless. As an example, `rust-bitcoin`
unnecessarily requires an explicit dependency on `bitcoin_hashes`.
Add `bitcoin-hashes-std` feature so that users do not need an explicit
dependency in the common use case.
Change the test matrix to only test '*-std' features when 'std' is
enabled since enabling one without the other is illogical. Please note,
this replaces the test run of feature 'std'+'rand'+'rand-std' with just
'std'+'rand-std' because enabling 'rand-std' enables 'rand' so the
explicit additional feature is redundant.
Currently we use default features for the `bitcoin_hashes` dependency,
doing so breaks the `no-std` feature in `rust-bitcoin` because `std` is
part of `bitcoin_hashes` default feature set.
Disable `bitcoin_hashes` default features, no changes to `rust-bitcoin`
are require after this change since we manually turn on `std` and
`alloc` as part of the `std`/`no-std` features of `rust-bitcoin`.
For other users of `rust-secp256k1` this is a breaking change but is
unlikely to cause too much bother because `std` is so commonly used.
Mirror the whitespacing in `rust-bitcoin` by doing:
- Only use single line of whitespace between sections
- Separate optional dependencies from non-optional ones
65d32af6fd bump version to 0.21.3 (Andrew Poelstra)
Pull request description:
We've got a ton of minor changes in, plus fixing the Parity type and adding some extra serde impls. Let's push a minor version out so that we can move on to updating the upstream libsecp.
Top commit has no ACKs.
Tree-SHA512: 584c03106124b4152b8971ac6d0587a26d2aca9187f88d8228a356c2327bf066d2c9b8134149f9ee3bc5f3712f64559b32843aa8e92d3395c5a1bd53de5442ce
Instead of providing a mechanism for users to opt out of randomization
we can just feature gate the call site i.e., opportunistically randomize
the global context on creation if `rand-std` feature is enabled.
Tobin C. Harding
Andrew Poelstra
Davidson Souza
elsirion
Artem Vorotnikov
Elichai Turkel
Dominik Spicher