e9e17a0039 Check for changes to the public API (Tobin C. Harding)
Pull request description:
We would like to get to a stage where we can commit to the public API. To help us achieve this add a script that generates the public API and checks it against three committed files, one for each feature set: no features, alloc, std.
The idea is that with this applied any PR that changes the public API should include a final patch that is just the changes to the api/*.txt files, that way reviewers can discuss the changes without even needing to look at the code, quickly giving concept ACK/NACKs. We also run the script in CI to make sure we have not accidentally changed the public API so that we can be confident that don't break semver during releases. The script can also be used to diff between two release versions to get a complete list of API changes, useful for writing release notes and for users upgrading.
There is a development burden involved if we apply this patch.
ACKs for top commit:
apoelstra:
ACK e9e17a0039
Tree-SHA512: 94a2cedb132db457b67b3c60cde8843d9db1d2bc8dba0530cd5c518ebed955bd66a1649c61e0cb96b6f293ce6b9b0395582877ce9f1de003e0020a66100d172f
We would like to get to a stage where we can commit to the public API.
To help us achieve this add a script that generates the public API and
checks it against three committed files, one for each feature set: no
features, alloc, std.
The idea is that with this applied any PR that changes the public API
should include a final patch that is just the changes to the api/*.txt
files, that way reviewers can discuss the changes without even needing
to look at the code, quickly giving concept ACK/NACKs. We also run the
script in CI to make sure we have not accidentally changed the public
API so that we can be confident that don't break semver during releases.
The script can also be used to diff between two release versions to get
a complete list of API changes, useful for writing release notes and for
users upgrading.
There is a development burden involved if we apply this patch.
3dc5b16540 Bump version to v0.28.0 (Tobin C. Harding)
Pull request description:
Bump the version of `secp256k1` ready for release.
Includes changelog for the already-bumped `secp256k1-sys`, changelog for `secp256k1`, and the version bump for `secp256k1`.
ACKs for top commit:
apoelstra:
ACK 3dc5b16540
Tree-SHA512: 404a5512f7bb245cde12d11eb20f2e7bedfa5a8d4124101e04bf51010301fe7d186c3baedf8744006d1c56c0af1bf214f0226c71a54dc6677384ecc8dcc8fde0
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.
39febcb866 Create rust-bidings (Davidson Souza)
Pull request description:
~**Marking as draft as this is an unreleased feature from libsecp**~
From upstream:
This implements encoding of curve points using the ElligatorSwift algorithm, using 4 new API calls:
secp256k1_ellswift_encode, which converts a public key to a 64-byte pseudorandom encoding.
secp256k1_ellswift_decode, the reverse operation to convert back to normal public keys.
secp256k1_ellswift_create, which can be seen as a combination of secp256k1_ec_pubkey_create + secp256k1_ellswift_encode, but is somewhat safer.
secp256k1_ellswift_xdh, which implements x-only Diffie-Hellman directly on top of 64-byte encoded public keys, and more efficiently than decoding + invoking normal ECDH.
This algorithm allows mapping any pair of field elements (u, t) to a (valid) x coordinate in the curve. This allows representing a field element as a 64-bytes bit string that is indistinguishable from random. You can build a pair of (u, t) from any group element as well.
We also have an integrated x-only ECDH that can be used to establish a shared secret between two parties. All algorithms are compatible with BIP324 and are tested against the BIP's test cases.
I have a few questions about the rust side of the implementation:
Should it be always on, or leave it behind a cargo feature? In `libsecp` this module is default on, but you can disable it.
I'm not exposing the low-level functions, instead you can use high-level types to interact with ellswift. Is it reasonable to also expose a safe version of the functions above?
ACKs for top commit:
tcharding:
ACK 39febcb866
apoelstra:
ACK 39febcb866
Tree-SHA512: a3c06304a03af9509ff3ef16fd39ee56ec22fc12d1b36be4c20aaa2ad01e98dd34ea64c66db782d3a2c10c3a7b44c701762d45f8d82f45b62db3379710c89c42
Create bindings for all methods and static types in ellswift.h in
secp256k1-sys and their respective safe-rust types.
All methods are extensively commented and tested using BIP324's
test vectors
80b2a8d4aa Update vendored libsecp to v0.4.0 (Davidson Souza)
d2285c929a ci: Remove MIPS* from CI (Davidson Souza)
0d58f50d52 ci: generalize grp in "illegal callback" test (Andrew Poelstra)
acf9ac13e9 delete `test_manual_create_destroy` test (Andrew Poelstra)
04ce50891b lib: fix bad unit test (Andrew Poelstra)
e4cca901ea gitignore: remove things that shouldn't be there (Andrew Poelstra)
Pull request description:
Replaces #645 and #652. Precedes #627.
I'm basically using #652 but resolving the linking problems,
My local CI is erring on windows cross-test, but I can compile without issue with `cargo build --target x86_64-pc-windows-gnu`. Some MIPS jobs failed before even installing cross, I think those aren't really related to this PR. Any ideas on what can be happening?
ACKs for top commit:
apoelstra:
ACK 80b2a8d4aa
Tree-SHA512: 62c2e04348110e3995111fa666f10dcc403b963770d047361f9209cf45b45db8744a7eb6d9ee3278d18007412dab5131ac3e1dd3e3d704963c6a6f232d57199a
MIPS was recently downgraded to Tier 3, which means it won't be installable by
rustup and may not work as expected. This commit removes all MIPS-related
CI jobs.
This is just a bad test. It constructs a preallocated context object by
starting from a non-preallocated context object, in a way that can't be
done by users (since it directly constructs a `Secp256k1` struct) and a
way that is very difficult to unwind, because you wind up with two
pointers to the same underlying context object, one a "preallocated" one
and one a normal one.
If you then drop the preallocated one, it will call
`secp256k1_context_destroy`, forcing you to manually deallocate the
other one. If you drop the normally-allocated one, you need to
mem::forget the preallocated one to avoid calling
`secp256k1_context_destroy` twice. The whole thing is pretty fragile.
There is another unit test, `test_raw_ctx`, which gets into the same
situation but using the public API, and demonstrates a few ways to get
out of it.
upstream libsecp now has a CMakeLists.txt file. Many years ago we added
some things to .gitignore which appear to be local developers committing
the names of their own stray files, and now this is causing the
revendoring script to lose track of vendored files.
936421476e Use range dependency for hashes v0.12.0 - v0.13.0 (Tobin C. Harding)
Pull request description:
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.
ACKs for top commit:
apoelstra:
ACK 936421476e
Tree-SHA512: c411acbd6025a751920fe2c432bf8c9ab78e891a3b32170f85873732c595777e075bd8b1277bf7b156e941a3caf532af71af36e99f88aa36dadbd66c61384166
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.
aa4489c71b key: Improve docs (Tobin C. Harding)
Pull request description:
`PublicKey` types are for verifying ECDSA signatures, when these docs where written there were no other types of signatures. With the addition of taproot these docs have become stale.
ACKs for top commit:
apoelstra:
ACK aa4489c71b
Tree-SHA512: bb24d82f2bf316f8907b1bf02132d454d21f0b13d57f06f09f9985bc7fbf7b36e6972a0fdaf3a68967577dbe1995f2a14fd06fddd38eb46718f04bca1c50a445
33747bb16f Rename KeyPair to Keypair (Tobin C. Harding)
Pull request description:
We use "keypair" in identifiers (local vars and function names) but `KeyPair` - one of them is wrong.
Elect to follow upstream and define keypair as a single word i.e., use `Keypair` for type name and `keypair` in identifiers.
This patch can be reproduced mechanically by doing two search-and-replace operations on all files excluding the CHANGELOG
- Replace "KeyPair" with "Keypair"
- Replace "key_pair" with "keypair"
Fix#647
ACKs for top commit:
apoelstra:
ACK 33747bb16f
Tree-SHA512: 2cb67cde3a39c4681e0628b17b12724fe17d00bc71e985b4eb0b3ad58d574f4a372aa782fc9cb7221cd2032d8312c579195ad2230a3eeb4c550865fa36e42c0b
We use "keypair" in identifiers (local vars and function names) but
`KeyPair` - one of them is wrong.
Elect to follow upstream and define keypair as a single word i.e., use
`Keypair` for type name and `keypair` in identifiers.
This patch can be reproduced mechanically by doing two
search-and-replace operations on all files excluding the CHANGELOG
- Replace "KeyPair" with "Keypair"
- Replace "key_pair" with "keypair"
6fdd3b1da5 Clean up hashes import statements (Tobin C. Harding)
6d7c653b64 Use hashes instead of bitcoin_hashes (Tobin C. Harding)
Pull request description:
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.
ACKs for top commit:
apoelstra:
ACK 6fdd3b1da5
Tree-SHA512: 2c6c81b6ef900bfe930df48ddd32e795997c107a2a94b9e2ea014da0be7aefaa952e1259ddb570b30f5ad7e94c0a9443b691645cb386a8d0349dc7a81f659ed6
Now that we have `hashes` as the crate name of `bitcoin_hashes` we can
slightly clean up the import statements.
This is based on the convention we have to import things directly from
the crate if we depend on it and not from the crate level re-export.
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?
3da39c6fb6 Run test with recent/minimal lock files (Tobin C. Harding)
4b9168ca25 Run WASM tests from test wrapper script (Tobin C. Harding)
637d08f1fe Add a layer of indirection to the test script (Tobin C. Harding)
d9b70d27b0 Remove trailing whitespace (Tobin C. Harding)
461bae9244 Move recent/minimal lock files (Tobin C. Harding)
Pull request description:
A while back we added two lock files, one for testing with recent dependency versions and one for testing with minimal dependency versions but at the time we never used them in CI.
Move the two current lock files and use them in CI (mirroring what is done in `rust-bitcoin`).
ACKs for top commit:
apoelstra:
ACK 3da39c6fb6
Tree-SHA512: 5d293689e8a67373cbf0d6b04894c38e636bb7da19db62ac2cc1b83f1dc8184e92169a834d9adf4de3c61c34d5f6f443a1be1d0c2503bb03f08fc486d68beb71
The `wasm-pack` command does not honour `cargo` flags passed to it so we
cannot use `--locked` and test against pre-made lock files. Instead just
run the WASM test from the test script wrapper.
We would like to be able to run the test script with different lock
files, in preparation for doing so move the `test.sh` script to
`_test.sh` and add a new `test.sh` that runs `_test.sh`.
Keep the outer script as `test.sh` so that we do not change the workflow
for those running the script including the github actions.
A while back we added two lock files that were to track dependencies of
two successful test runs, one with a minimal set of dependencies and one
with a recent set of dependencies (ie, recent dependency versions). We
never used these lock files in CI however.
In preparation for using the lock files in CI, and in order to be
uniform with `rust-bitcoin`, move the lock files to the crate root and
rename them to:
- Cargo-minimal.lock
- Cargo-recent.lock
b9cb37d69f Add a verify function to PublicKey (Tobin C. Harding)
Pull request description:
To be uniform with `XOnlyPublicKey` add a `verify` function to the `PublicKey`.
Should have been done when we did #618
ACKs for top commit:
apoelstra:
ACK b9cb37d69f
Tree-SHA512: e1d8127daafd18d3c9b5df6edc46a961ed49e87a44c650b92c695606002f1d4c1aee3e89822e188a65ba888abd50c5b6f247570d73fa8508d739efa8bc4df7f0
cd40ae7f19 Improve Message constructors (Tobin C. Harding)
Pull request description:
Observe:
- The word "hash" can be a verb or a noun, its usage in function names is therefore at times ambiguous.
- The function name `from_slice` gives no indication as to what the slice input is.
Improve Message constructors by doing:
- Add a constructor `Message::from_digest` that takes a 32 byte array as input.
- Rename `Message::from_slice` to `Message::from_digest_slice` (deprecate `from_slice` and add `from_digest_slice`)
- Improve the docs while we are at it.
### Note
The original PR conflate 2 separate issues, the `Message` constructor naming clarity issue and the upgrade difficulty issue, PR is now only a solution to the first. The second will be done as a separate PR.
ACKs for top commit:
apoelstra:
ACK cd40ae7f19
Tree-SHA512: 4e5aeccf15cca95073f4c3a518b9e1f54f0e33c92c45dfecd1daa31d052022cd28c71bb6df6cff8a6548993e3e22788f11cd2633214ab5a580c753e66d2ea749
92778efe92 CI: Pin cc in ASAN no_std_test crate (Tobin C. Harding)
5e6dd8a467 CI: Use bash instead of sh (Tobin C. Harding)
cf5f1034ca Target panic message at lib users (Tobin C. Harding)
ec9c9643d7 Allow stuff after unconditional panic (Tobin C. Harding)
3bbf08348e no_std_test: Remove internal_features (Tobin C. Harding)
cff7a3dae7 CI: Grep for exact error message (Tobin C. Harding)
79e184f08a CI: Update MSRV pins (Tobin C. Harding)
Pull request description:
CI has a bunch of things broken.
This is #640 followed by #639 followed by a few addition fixes to get CI green again. Includes clippy warnings in feature gated code which is not strictly necessary and a fix to a panic message, also not strictly necessary.
ACKs for top commit:
apoelstra:
ACK 92778efe92
Tree-SHA512: f99b01e17fade7df394299bdb6bf385bec3f88d6568d43962238049b33a94c364d48c266acb358e72a48dd55a4aac6300ace6478b0821275b89cb86eba639d8b
Currently the panic message refers to stuff related to development of
the library, this is meaningless for users of the lib. Target panic
message at secp users instead.
We have an unconditional panic for some combination of features, this
causes clippy to give a bunch of useless warnings.
Add allow attributes to quieten down clippy.
`cargo +nightly` output of panic recently changed breaking our grep
statement by adding the code line and a newline.
Grep for the exact second line of the error message.
Pinning is broken again, update the pins it CI so that the following
sequence of commands would work
```bash
rm Cargo.lock
cargo +1.48 update -p wasm-bindgen-test --precise 0.3.34
cargo +1.48 update -p serde_test --precise 1.0.175
cargo +1.48 test --all-features
```
Note, solely out of interest, `cargo +1.48 build` does not need
pinning (at the moment :)
Observe:
- The word "hash" can be a verb or a noun, its usage in function names
is therefore at times ambiguous.
- The function name `from_slice` gives no indication as to what the
slice input is.
Improve Message constructors by doing:
- Add a constructor `Message::from_digest` that takes a 32 byte array as
input.
- Rename `Message::from_slice` to `Message::from_digest_slice`
(deprecate `from_slice` and add `from_digest_slice`)
- Improve the docs while we are at it.
567c39c7f1 Revert "WIP: Add toolchain matrix to job" (Tobin C. Harding)
e6643c083d CI: Pin dependencies for MSRV build ... properly (Tobin C. Harding)
Pull request description:
Goodness me, I made a mess.
Commit `0e0dcb7f CI: Pin dependencies required for MSRV build` is totally wrong, why did it get through CI?
Fix broken stuff in the CI script by doing:
- `serde_json` is not a dependency of `secp256k1`, remove the pinning
- Put the pinning _before_ any call to `cargo`
- Pin the transient dependency `wasm-bindgen-test`
And then `Revert "WIP: Add toolchain matrix to job"`
Fix: #626
ACKs for top commit:
apoelstra:
ACK 567c39c7f1
Tree-SHA512: f60a95e1c840e265dba1d10d2e87b970f1ebc5f01514ef9edaaf0475d833dbce15b8e715a6c53052786036b1dbbba73a2be0e470afd0d37320f540081c51c8e8
This reverts commit 77808b7d83.
dtolnay/rust-toolchain does not support using a matrix as far as I can
tell. Since the PR brief description contains "WIP" it looks like the
original author (me) was testing this using CI, no idea how this patch
got merged.
Commit `0e0dcb7f CI: Pin dependencies required for MSRV build` is
totally wrong, why did it get through CI?
In the CI script do:
- `serde_json` is not a dependency of `secp256k1`, remove the pinning
- Put the pinning _before_ any call to `cargo`
- Pin the transient dependency `wasm-bindgen-test`
81b154fed5 Remove docsrs cfg_attributes (Tobin C. Harding)
Pull request description:
We no longer need to manually configure the docsrs build to highlight feature guards since we use the `doc_auto_cfg` feature. Somehow when we added usage of that feature we forgot to remove the other attributes.
Found in CI fail of #624
ACKs for top commit:
sanket1729:
utACK 81b154fed5. I don't follow this completely, but yay for removing unnecessary code.
apoelstra:
ACK 81b154fed5
Tree-SHA512: 9decdc3f71d8f592047eee89f7f4aaf3a08b2643148c6bc5ad7de9edf61acab0ee56bf3c6dbc14493a9d089d492e31f1d379539e256b5eb96c8873c3be702256
We no longer need to manually configure the docsrs build to highlight
feature guards since we use the `doc_auto_cfg` feature. Somehow when we
added usage of that feature we forgot to remove the other attributes.
0e0dcb7f54 CI: Pin dependencies required for MSRV build (Tobin C. Harding)
Pull request description:
Whinge, whinge, whinge, and pin the dependencies.
ACKs for top commit:
apoelstra:
ACK 0e0dcb7f54
Tree-SHA512: 3eb65a844f632ea324705fe371c3876b96d62ddabe17085ed1bf32183eb491ff5006836c3945f4b0e11886049e9bd62245d2eb2c646cbf1a2f10cbff5c54bd53
3b8a82eb2b Add changelog entry for removal of ONE_KEY (Tobin C. Harding)
Pull request description:
In the 0.25.0 release we removed the `ONE_KEY` const but did not mention it in the release notes. This makes upgrade harder than it should be.
In hindsight we should have deprecated the const then removed it.
Add a changelog entry to the 0.25.0 release mentioning the removal and the work around.
ACKs for top commit:
apoelstra:
ACK 3b8a82eb2b
Tree-SHA512: 0bbf47a2f0e5221719b3d04a895c8f784623e31fd149911cf1b92afa2487037ee9619cedc94ea1d22bffd540ef5aa94a56e98daa56751c94274c973825ec9d5d
d60b891126 Add a verify function to PublicKey (Tobin C. Harding)
Pull request description:
Expose signature verification functionality for schnorr signatures on the `XOnlyPublicKey` type.
Idea from Kixunil: https://github.com/rust-bitcoin/rust-bitcoin/pull/1744#issuecomment-1534200841
ACKs for top commit:
apoelstra:
ACK d60b891126
Tree-SHA512: 2ffa3de528b857c5b0a402815b71b35da913c668bea53b63801705fa6a86eb6d44766aa2395c02f67a4712b451c77caf627af9450183ae70957abf246a63c279
In the 0.25.0 release we removed the `ONE_KEY` const but did not mention
it in the release notes. This makes upgrade harder than it should be.
In hindsight we should have deprecated the const then removed it.
Add a changelog entry to the 0.25.0 release mentioning the removal and
the work around.
Andrew Poelstra
Tobin C. Harding
Davidson Souza