We recently added fixed width serialization for some types however
serialization is only fixed width when data is serialized with the
`bincode` crate.
Add rustdocs describing fixed width serde to `SecretKey`, `PublicKey`,
and `XOnlyPublicKey` (`KeyPair` is already done).
Currently the rustdocs for `KeyPair` are stale in regards to serde, we
_do_ implement `Serialize` and `Deserialize` for `KeyPair`.
Improve the rustdocs for `KeyPair` by removing stale docs and adding
docs on fixed width binary serialization.
Currently we serialize keys using the `BytesVisitor`, this causes the
serialized data to contain additional metadata encoding the length (an
extra 8 bytes) when serialized with the `bincode` crate. This extra data
is unnecessary since we know in advance the length of these types.
It would be useful for users of the lib to be able to get a fixed width
binary serialization, this can be done but it depends on the crate used
to do the serialization. We elect to optimise for `bincode` and add docs
noting that other binary serialization crates may differ (rustdocs added
in separate patches).
Implement a tuple based visitor that encodes the keys as fixed width
data.
Do fixed width serde implementations for:
- `SecretKey`
- `PublicKey`
- `KeyPair`
- `XOnlyPublicKey`
5d2f1ceb64 Fix WASM build (Elichai Turkel)
39aaac6834 Use new trait TryFrom and do small refactoring (Elichai Turkel)
7d3a149ca5 Move more things from the std feature to the alloc feature (Elichai Turkel)
bc8c713631 Replace c_void with core::ffi::c_void (Elichai Turkel)
26a52bc8c8 Update secp256k1-sys to edition 2018 and fix imports (Elichai Turkel)
ebe46a4d4e Update rand to 0.8 and replace CounterRng with mock::StepRng (Elichai Turkel)
626835f540 Update secp256k1 to edition 2018 and fix imports (Elichai Turkel)
67c0922a46 Update MSRV in CI and Readme from 1.29 to 1.41 (Elichai Turkel)
Pull request description:
As proposed in https://github.com/rust-bitcoin/rust-bitcoin/issues/510#issuecomment-881686342 this PR raises the MSRV to 1.41.1 it also changes the code to be Edition 2018.
The PR contains a few things:
* Moving to edition 2018 and fixing the imports
* Sorting and combining imports to make them more concise
* Replacing our c_void with `core::ffi::c_void`
* Bumping the `rand` version to latest and modifying our `RngCore` implementations accordingly
* Doing some small refactoring and using the new `TryInto` trait where it makes the code nicer
If people prefer I can split this PR into multiple and/or drop some commits
ACKs for top commit:
tcharding:
ACK 5d2f1ceb64
apoelstra:
ACK 5d2f1ceb64
Tree-SHA512: 5bf84e7ebb6286d59f8cada0bb712c46336f0dd6c35b67e6f4ba323b5484ad925b99b73e778ae4608f123938e7ee8705a0aec576cd9c065072c4ecf1248e3470
0b27bde60b Bump secp256k1-sys minor version (Tibo-lg)
4beebd168e Add secp256k1_schnorrsig_sign_custom to sys crate (Tibo-lg)
Pull request description:
Trying to update to the latest version I noticed that I lost the ability to pass a nonce to the schnorr signing function. This PR restore this ability by adding `secp256k1_schnorrsig_sign_custom` to the sys crate.
I hid the struct members of `SchnorrSigExtraParams` and added a `new` method to make sure that the `magic` field is properly initialized, I think that make the most sense but happy to hear other opinions.
ACKs for top commit:
apoelstra:
ACK 0b27bde60b
Tree-SHA512: 7181eddb5815ca1a5ae1044f2a6fd8a214f8df9c45352e5f2ab6607f7e0d819cb8856fc2d6596b9d740b859df91d559595e7912332e292079c9ac1d27ec5c00b
ef7f1972a7 Derive Hash for Signature (Tobin C. Harding)
Pull request description:
In preparation for deriving `Hash` in miniscript, derive `Hash` on the `ecdsa::Signature`.
ref: https://github.com/rust-bitcoin/rust-miniscript/issues/226
ACKs for top commit:
apoelstra:
ACK ef7f1972a7
elichai:
ACK ef7f1972a7
Tree-SHA512: 7313f59971444ae18611adbafe86a09478eddd7357f2b7f3ad3bb1761609b6358b156975086f6c318eb2777018b7b2f44386321108939acbcf2d0a522e7e208e
997b4b35a9 Fix depreciation warning typos (Tibo-lg)
Pull request description:
It got me confused for a second, might save a few minutes to the next person :).
ACKs for top commit:
apoelstra:
ACK 997b4b35a9
Tree-SHA512: 313409bec0841c1dae6dd54511fad5ecf3ffbc48ea8df18d0916a299f60f38b7fd204f7d8720a89539ad8fc329bbea5f6eabf573278f773a0b982f72af31acf2
3ed7fb044c release minor version of secp-sys with WASM fix (Andrew Poelstra)
Pull request description:
Would like to get this quickly merged and published before we merge the breaking edition stuff.
ACKs for top commit:
tcharding:
ACK 3ed7fb044c
elichai:
ACK 3ed7fb044c
Tree-SHA512: 02bade244b3e59ab438432ae9a01e75a41052c6d714d6485caeb88cfa3d0e3b0f3f970d339ceb24c2c4eb8f2d8ae4be2339272ab72a3115148ad0943c853efea
f08276adfc Add convenience methods for keys (Tobin Harding)
b4c7fa0d4e Let the compiler work out int size (Tobin Harding)
c612130864 Borrow secret key (Tobin Harding)
Pull request description:
We have a bunch of `from_<key>` methods for converting between key types. To make the API more ergonomic to use we can add methods that do the same but called on a variable e.g., once applied the following are equivalent:
- `let pk = PublicKey::from_keypair(kp)`
- `let pk = kp.public_key()`
Do this for `SecretKey`, `PublicKey`, `KeyPair`, and `XOnlyKeyPair`.
Fixes: #428
### Note to reviewers
- `XOnlyPublicKey` -> `PublicKey` logic is made up by me, I could not work out how to get `libsecp256k1` to do this.
- Please review the tests carefully, they include assumptions based on my current understanding of the cryptography :)
ACKs for top commit:
sanket1729:
ACK f08276adfc. Thanks for going through all the iterations.
apoelstra:
ACK f08276adfc
Tree-SHA512: 1503a6e570a3958110c6f24cd6d075fe5694b3b32b91a7a9d332c63aa0806198ff10bdd95e7f9de0cf73cbf4e3655c6826bd04e5044d1b019f551471b187c8ea
dc1e377d4e Improve docs on rustsecp256k1_v0_4_1_context_create (Tobin C. Harding)
ad153d82f7 Add safety rustdoc headings (Tobin C. Harding)
Pull request description:
Do some minor docs improvements.
Done in an effort to clear _all_ clippy warnings from the codebase.
ACKs for top commit:
sanket1729:
ACK dc1e377d4e
apoelstra:
ACK dc1e377d4e
Tree-SHA512: 9b7e3ff05a6ea05bde5df49bbfcc6eb2c7097b4d9b600dedeb8fef4e3cbdd56a357fd0846ca51cb32f0957bca1335ff3b4b0d771046481ab95447af99d6a2d9c
Clippy warns about unsafe code without a `# Safety` section. A bunch of
these warnings are for functions that do actually have safety docs.
Follow rustdoc convention and add a `# Safety` section for the already
existing explanations.
676a9800df Remove unnecessary panic message (sanket1729)
aa50cc6ced Remove Schnorr word from keypairs (sanket1729)
Pull request description:
Keypairs are pair of EC points that don't have anything to do with the
signature algorithm
ACKs for top commit:
apoelstra:
ACK 676a9800df
tcharding:
ACK 676a9800df
Tree-SHA512: ed3e6f5e821d18641234b308b130271dcd2ec0dd6519a0e9d91564ab8e902b82180d7df377f2bcf08cd3ca1df7ce775422e4a3c386637eaff348e58b033de3ea
We have a bunch of `from_<key>` methods for converting between key types.
To improve the API and make it more ergonomic to use we can add methods
that do the same but can be called on the initial key instead of on the
resulting key's type. E.g. once applied the following are equivalent:
- `let pk = PublicKey::from_keypair(kp)`
- `let pk = kp.public_key()`
Do this for `SecretKey`, `PublicKey`, `KeyPair`, and `XOnlyKeyPair`.
We have two places in the code where we pass a mutable parity integer
to ffi code. At one callsite we tell the compiler explicitly what type
it is (`::secp256k1_sys::types::c_int`) and at the other call site we
let the compiler figure out the type.
Is one way better than the other? I don't know. But letting the compiler
figure it out seems to make the code easier to read.
`SecretKey` implements `Copy` and it is fine to take owneship of it; we
have multiple methods called `from_secret_key` and they all borrow the
secret key parameter. Favour consistency over perfection.
Borrow secret key parameter as is done in other `from_secret_key`
methods.
97dc0ea9ac Run correct clang --version (Tobin Harding)
a3582ff77d test.sh: Use set -e to exit on failure (Tobin Harding)
7bec31c3a6 test.sh: explicitly return 0 (Tobin Harding)
Pull request description:
Change the test script to exit with non-zero status code if any command fails.
The `test.sh` script is silently failing, that means changes causing failures are slipping through our CI pipeline and being merged.
Resolves: #419
## Note
Just the last 3 patches, the first 6 are from #420. re-base just shows it works on top of 420, it is going to have to be rebased again when 420 merges.
ACKs for top commit:
apoelstra:
ACK 97dc0ea9ac
Tree-SHA512: b86a6876d8c45a2b90b7b3c8adbc08ad6f49b430b1cfaec31cd2de8441cb96af39c63da02b98d6ed71dfab045d466d71d3757297886b5e44ebb6cbaeb4ed32dd
58db1b6753 Run WASM for multiple toolchains (Tobin Harding)
946ac3b51e Do docs build in Nightly job (Tobin Harding)
f7bc7d3728 Install clang to run adress sanitizer (Tobin Harding)
96685c571d Remove unnecessary matrix (Tobin Harding)
a8a679ed7d Re-name nightly CI job to Nightly (Tobin Harding)
9c9d622b0e Remove trailing whitespace (Tobin Harding)
Pull request description:
Improve the CI pipeline. Done while investigating #419. This PR now only includes the GitHub actions changes, I'm moving the `test.sh` changes to a https://github.com/rust-bitcoin/rust-secp256k1/pull/422 because they cannot be merged yet.
(Please note, this PR has been heavily re-worked so discussion below may be confusing to reviewers new to the PR.)
ACKs for top commit:
apoelstra:
ACK 58db1b6753
thomaseizinger:
ACK 58db1b6753
Tree-SHA512: 5520cf7a7ea0ba701aeaf6b97150416192c0629df8b65545a20d8937a4d76bd323a0d7a875deccb7ce9adc4f3a423e6cd27b300682f206f79407f5ab4eaa5ddb
For the test that uses `clang-9` do the sanity call using `clang-9`
instead of `clang`.
For the test that uses `clang` add a sanity call to `clang --version`.
Currently the `test.sh` script is silently failing because we do not
exit if a command fails. We can achieve this by using the Bash builtin
`set -e`.
For some reason I cannot explain a chain of commands that fails does not
fail the script. Instead of working out _why_ just remove the chain and
run each command on its own. This is functionally the same and, I hazard
a guess, is what the original author hoped to achieve with the chaining.
bfd88dbd6c Move WASM const definitions to a source file (Tobin Harding)
Pull request description:
Total re-write ... again :)
Currently we are defining the WASM integer size and alignments in the `stdio.h` header file, this is wrong because this file is included in the build by way of `build.rs` as well as by upstream `libsecp256k1`.
Move WASM integer definitions to a `C` source file and build the file into the binary if target is WASM.
Fixes the first part of #419 (#422 does the second part).
### Note to reviewers
I'm not exactly sure why the directory `was-sysroot` is named as it is or if the name is significant to `cargo` , please review carefully the directory tree changes.
```
cd secp256k1-sys
tree wasm
wasm
├── wasm.c
└── wasm-sysroot
├── stdio.h
├── stdlib.h
└── string.h
```
ACKs for top commit:
thomaseizinger:
ACK bfd88dbd6c
apoelstra:
ACK bfd88dbd6c
Tree-SHA512: ba822b764fb5f74dfd22cc797f7e3f70440dbaabfe34e0475c796e0e5d88f2086bedb00a1ec765cce91bde6bb45130b9abe5d9289317d6c20f692c6ed711969e
d2e1f8cc95 Move panic test to top of script (Tobin Harding)
Pull request description:
In `test.sh` we have a test that checks for a panic by greping the output of `cargo test --exact 'tests::test_panic_raw_ctx_should_terminate_abnormally'`. If we put this test at the top of the script right after we run `cargo test` we are guaranteed to not trigger a re-build.
### Note to reviewers
I just noticed this patch somehow snuck into #420, all other changes in that PR are to `.github/workflows/rust.yml` so this change does not fit in there. Hence raising it as a separate PR.
ACKs for top commit:
apoelstra:
ACK d2e1f8cc95
Tree-SHA512: 90ad7a8762a6fd977345f347f0aa8b0979a7576585000b6d80624c0672b7de457dec471dc63b2e7fa4c3f52143d0f6fd1f4031a70f85c9fab4b7c22a787c438b
Currently we are defining the WASM integer size and alignments in the
`stdio.h` header file, this is wrong because this file is included in
the build by way of `build.rs` as well as by upstream `libsecp256k1`.
Move WASM integer definitions to a `C` source file and build the file
into the binary if target is WASM.
WASM is supported by Rust 1.30. We can therefore run the WASM tests on
any all the toolchains except MSRV (1.29.0). This has benefit of
catching nightly/beta issues before they get to stable.
Done as a separate CI job since it is conceptually different to the
`Tests` job.
Run WASM for nightly, beta, and stable toolchains.
We have a separate CI job for things that require a nightly toolchain.
Building the docs requires a nightly toolchain (because of `--cfg
docsrc` flag). It makes more sense to run the docs build in the
`Nightly` job instead of hidden in the `Tests` job.
Do the docs build in the `Nightly` job instead of in the `Tests` job.
The address sanitizer job is silently failing at the moment because we
do not install clang.
Install clang so the address sanitizer job can run. Do not fix the
silent failure, that will be done later on.
In line with the `Tests` job and for the fact that this job does stuff
with the nightly toolchain other than bench.
Re-name nightly CI job from `bench_nightly`to `Nightly`.
The test that checks for a panic uses `cargo test --exact`, it makes
sense to put it at the top of the script right after we run `cargo test`
so we can run the test without triggering a re-build.
c1bb316675 Make global-context-less-secure actually enable the global context (Elichai Turkel)
Pull request description:
In #407 we restored the `global-context-less-secure` feature, but it didn't actually do anything because #385 changed all the cfg checks on the whole module to depend on `global-context`, so we need to enable `global-context` in order to make that module compile.
so before all this, users could enable *just* `global-context-less-secure` without enabling the `global-context`, and after this PR it will behave the same.
(this will not enable the randomization because of: 1cf2429b12/src/context.rs (L51))
ACKs for top commit:
apoelstra:
ACK c1bb316675
Tree-SHA512: edc7b4916b359a0696cc25f498bc52ad340f981ad6b01b83b68966d6179200bac6acb96f5480157e24c605b5552bdd7b6eb8770bc9a2c5734da3df11c021fb5b
f93ca81348 Add sign_ecdsa_with_noncedata and sign_ecdsa_recoverable_with_noncedata (junderw)
Pull request description:
Fixes#424
As discussed on [IRC](https://gnusha.org/bitcoin-rust/2022-03-19.log) (starts at 09:14).
These methods will allow for users to generate multiple signatures with the same private key and message by utilizing one of the `Variants` mention in RFC6979 which is exposed by libsecp256k1 via the `noncedata` argument.
The reasoning behind adding this is to allow our library to migrate from using the -sys crate. Currently we support using this noncedata argument, and would like to continue doing so while at the same time migrating away from -sys crate.
ACKs for top commit:
apoelstra:
ACK f93ca81348
Tree-SHA512: 494d4f9046960779e199b18ff908fe74feda66a5cfc066c9ae6f3836fcaabd56defaa2138a913b25f1af3aa7dd48986e058804223224b76b303837c0c7adbaed
Tobin Harding
Andrew Poelstra
Elichai Turkel
Tibo-lg
junderw
sanket1729