d244b4d747 Fix typo in docs (Thomas Eizinger)
c5c95513f2 Move helper function below usage (Thomas Eizinger)
ce4427747d Move ECDSA functionality into ECDSA module (Thomas Eizinger)
e0c3bb28c4 Rename schnorr functions on `Secp256k1` to match naming of ecdsa (Thomas Eizinger)
760559c70e Rename `schnorrsig` module to `schnorr` (Thomas Eizinger)
d4fb819d80 Move `XOnlyPublicKey` to `key` module (Thomas Eizinger)
87d936a765 Rename `schnorr::PublicKey` to `schnorr::XOnlyPublicKey` (Thomas Eizinger)
2e0e731664 Move `KeyPair` to `key` module (Thomas Eizinger)
c47ead9967 Move `Signature` and `SerializedSignature` to new `ecdsa` module (Thomas Eizinger)
49c7e21486 Prefer `use super::*` import over manually picking items (Thomas Eizinger)
52d0554423 Fully qualify Error to simplify imports (Thomas Eizinger)
8e96abae39 Make `key` module private (Thomas Eizinger)
Pull request description:
This patch-set tries to re-structure the library a bit. What we currently have seems to have been mostly driven by historical growth. For example, with the addition of Schnorr signatures, just exposing `secp256k1::Signature` is ambiguous.
This PR only contains renames and moving around of code. I've tried to structure the patches in such a way that makes this reasonably easy to review. Feedback welcome!
ACKs for top commit:
sanket1729:
ACK d244b4d747
apoelstra:
ACK d244b4d747
Tree-SHA512: d40af5c56ffa500305e40eb5dbe72f2f6d6193b3a190910018d3bacdec2820ab6a59f15d47d11e0fee7ef4de6efd46d316636cd502aad5db4f314dedfff726f9
The public key is unrelated to the signature algorithm. It will
be moved out of the module in another commit. For ease of review,
the renamed is kept separate.
With the introduction of Schnorr signatures, exporting a `Signature`
type without any further qualification is ambiguous. To minimize the
ambiguity, the `ecdsa` module is public which should encourage users
to refer to its types as `ecdsa::Signature` and `ecdsa::SerializedSignature`.
To reduce ambiguity in the APIs on `Secp256k1`, we deprecate several
fucntions and introduce new variants that explicitly mention the use of
the ECDSA signature algorithm.
Due to the move of `Signature` and `SerializedSignature` to a new module,
this patch is a breaking change. The impact is minimal though and fixing the
compile errors encourages a qualified naming of the type.
75b49efb3d Implement `Hash` for all array newtypes (elsirion)
Pull request description:
I pondered putting the impl into the array type macro together with `(Partial)Eq`, but that would have meant removing other implementations and potentially implementing it for types where it is not wanted. The drawback of the separate impl is that it is more disconnected from the `(Partial)Eq` impl and could theoretically diverge (although unlikely in case of such a simple type) which would break the trait's contract.
ACKs for top commit:
apoelstra:
ACK 75b49efb3d
Tree-SHA512: 44d1bebdd3437dfd86de8b475f12097c4a2f872905c822a9cde624089fdc20f68f59a7734fdcc6f3a17ed233f70f63258dfd204ca269d2baf8002ffc325ddc87
801c3789c4 disable illumos and netbsd (Riccardo Casatta)
a426456bfa [CI] add cache (Riccardo Casatta)
f1bdee210a add cross testing on rust tier 1 and tier 2 with host tools (Riccardo Casatta)
Pull request description:
After working on https://github.com/rust-bitcoin/rust-bitcoin/pull/627 I thought it may be simple and useful to use [cross](https://github.com/rust-embedded/cross) environment to test across different architectures and started here.
So I took all rust tier1 and tier2 with Host tools archictectures and added to the test matrix, run here https://github.com/RCasatta/rust-secp256k1/actions/runs/985791240.
Errors on darwin are due to the environment because it works fine on physical machine, however errors on illumos and netbsd maybe are useful to know?
ACKs for top commit:
apoelstra:
utACK 801c3789c4
Tree-SHA512: 43c7220e41856344d4a932426d8acb8e9f004fcf33acfbde4b26f3a6074b0ce3e766d99afaca6c18381a4438775fa693b06c70d3204d83ff5a97fcbebe126056
24d6f62603 Use explicit u8 when assigning a byte slice (junderw)
Pull request description:
Is there a way to tell the compiler to not allow `[0; 64]` and require that either the type is explicitly given to the variable, or that each member uses explicit `0u8` notation?
I noticed the usage was a mix of explicit and implicit, so I changed all to explicit.
ACKs for top commit:
apoelstra:
ACK 24d6f62603
Tree-SHA512: f7796dcc3ae240983257bef0f25bd0df741943f75d86e9bca7c45076af179d96ce213bd9c339a01f721f7dc9b96a0a4a56ef2cf44339f4c91d208103b7659d9f
6810c2b547 Dedicated display_secret fn for secret-containing types (Dr Maxim Orlovsky)
635a6ae441 Add to_hex converter and add tests for hex conversion (Elichai Turkel)
Pull request description:
Extract of concept ACK part of #311 related to changing the way secret keys are displayed/printed out
ACKs for top commit:
apoelstra:
ACK 6810c2b547
thomaseizinger:
ACK 6810c2b547
Tree-SHA512: 22ad7b22f47b177e299ec133129d607f8c3ced1970c4c9bea6e81e49506534c7e15b4fb1d745ba1d3f85f27715f7793c6fef0b93f258037665b7f740b967afe5
bc42529a16 Rename `secp256k1::bitcoin_hashes` module to `secp256k1::hashes` (Thomas Eizinger)
ae1f8f4609 Bump bitcoin_hashes to version 0.10 (Thomas Eizinger)
Pull request description:
Requires for interoperability of the `ThirtyTwoByteHash` trait with
rust-bitcoin.
ACKs for top commit:
apoelstra:
ACK bc42529a16
Tree-SHA512: 85fcb284ff82b543a0c3ea2b568351b3af938a26ac42c6a975480ae97def84e4f0795105bd4572f930a7bf82654eba416cf0c5e25f62809e2ea331443ffb5807
junderw
Dr Maxim Orlovsky
Andrew Poelstra
Thomas Eizinger
elsirion
Riccardo Casatta
Elichai Turkel
Tibo-lg
sanket1729
Matt Corallo