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
This reduces the usage of real cryptography in --cfg=fuzzing,
specifically replacing the secret->public key derivation with a
simple copy and ECDH with XOR of the public and private parts
(plus a stream of 1s to make a test pass that expected non-0
output).
It leaves secret tweak addition/multiplication as-is.
It also changes the context creation to over-allocate and store
the context flags at the end of the context buffer, allowing us
to easily test context flags in each function.
While it would be nice to have something fancier (eg XOR-based),
its not immediately obvious how to accomplish this, and better to
fix the issues I have than spend too much time on it.
Fixes#271.
This partially reverts b811ec133a
In the next commit the secret->public key derivation in fuzzing cfg
is changed to be simpler, as well as the validity rules of public
keys relaxed.
This adds a new test to ensure random keys can be added, not just
the hard-coded keys test that exists today.
cc-rs builds C dependencies with reduced visibility to avoid
exporting the C symbols all the way out to any rust-built shared
libraries however we override it with SECP256K1_API. We should
avoid doing this, allowing LTO/DCE to do its work.
Panicking from C is not UB in newer rust versions and will reliably
trigger an abort (without unwinding). In older rust versions, it is
technically UB but empirically it seems to "just work" (and what should
it realistically do except crashing, which is what we intent).
Since there's potentially no unwinding, we can't test this behavior
using [should_panic]. This PR will instead check the libtest output
explicitly in our CI tests.
Fixes#228.
Andrew Poelstra
Dr Maxim Orlovsky
Elichai Turkel
Thomas Eizinger
Tibo-lg
Riccardo Casatta
sanket1729
Matt Corallo
Matt Corallo
Devrandom
Jules Comte
Tim Ruffing