Commit Graph

130 Commits

Author SHA1 Message Date
Thabokani b196f6b897
hashes: fix typos 2024-01-18 14:06:32 +08:00
Tobin C. Harding 3a562db39d
docs: Remove pinning from hashes readme
We do not need to pin with the current MSRV, remove the stale mention of
it from the `hashes` readme file.
2024-01-11 15:08:44 +11:00
shuoer86 cc45cfe3fe
Fix typos 2024-01-05 23:10:52 +08:00
Andrew Poelstra ada8c53ce2
Merge rust-bitcoin/rust-bitcoin#2272: hashes: Add Hash::from_bytes_iter to construct hashes from iterators
94a6caf204 hashes: Add Hash::from_byte_chunks to construct hashes from iterators (Steven Roose)

Pull request description:

  Is there any interest in a method like this? I'm not necessarily a fan myself, was just in a situation where I was doing this a lot and it would save the me the "engine, from_engine dance" each time.

ACKs for top commit:
  Kixunil:
    ACK 94a6caf204
  apoelstra:
    ACK 94a6caf204

Tree-SHA512: 96e74366dbf64d50fb6642024d18eeeee5b78154fa152c845a1073c904599af69328a141f0a7e2bd1a7b43a091c886da57dfe6e87bab5a5e01b0f167019caae0
2023-12-11 19:51:05 +00:00
Steven Roose 94a6caf204
hashes: Add Hash::from_byte_chunks to construct hashes from iterators 2023-12-11 08:41:12 +00:00
Tobin C. Harding 69e56a64ed
Add bitcoin-units crate
Add a new crate `bitcoin-units`, move the `amount` module over to it and
re-export all types from `bitcoin::amount` so this as not a breaking
change.
2023-12-11 08:52:31 +11:00
Tobin C. Harding 5c0759a390
Inline io module in io crate root
Its not immediately obvious why we nest the whole `io` code in an `io`
submodule within `lib.rs`. As far as I can tell we can inline it and
re-export from `rust-bitcoin` same as we do for our other dependencies.

This change would effect other users of the crate but since the `io`
crate is unreleased this effects no-one except us.
2023-11-28 14:17:14 +11:00
Tobin C. Harding 4d5415f835
Add rust-version to the workspace manifests
Add `rust-version = 1.56.1` to all crates in the workspace i.e.,
including `fuzz` but excluding the various test crates.
2023-11-23 06:20:04 +11:00
Tobin C. Harding a41e978855
Update to edition 2021
We just bumped the MSRV to Rust 1.56.1 which includes edition 2021.

Update all crates in this repo to use edition 2021 and build/lint
warnings.
2023-11-23 06:20:03 +11:00
Tobin C. Harding d9cc724187
Bump MSRV to Rust version 1.56.1
Rust version 1.56.0 introduced edition 2021. Shortly afterwards, on
October 21 2021 Rust version 1.56.1 was released.

Debian stable is currently shipping `rustc 1.63.0`.

Our stated MSRV policy is: In Debian stable and at least 2 years old.

Therefore our MSRV policy is met by Rust version 1.56.1 and we can strat
to bump our MSRV org wide.

Start by bumping the `rust-bitcoin` and `hashes` MSRV to Rust 1.56.1,
includes:

- Update docs.
- Update CI and remove pinning.
- Update the build files and remove now stale cfg attributes rust_v_1_x
  for values less than the new MSRV.
- Use new `IntoIterator` for arrays so we no longer need to allocate a
  vector to iterate.

Links:

- https://blog.rust-lang.org/2021/11/01/Rust-1.56.1.html
- https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html
- https://packages.debian.org/stable/rust/rustc
2023-11-23 06:20:02 +11:00
Tobin C. Harding 75c490c60f
hashes: Remove default features from schemars dep
We are trying to get rid of the `serde_derive` dependency from our
dependency graph.

Stop using default features for the `schemars` dependency which includes
`schemars_derive` which depends on `serder_derive`.

Manually implement `schemars::JsonSchema` instead of deriving it.
2023-11-20 15:18:33 +11:00
Tobin C. Harding 1105876423
Remove whitespace character from string
No whitespace needed here, this is likely a typo.
2023-11-20 15:17:31 +11:00
Matt Corallo add371d263 Remove `core2` dependency entirely 2023-11-09 16:46:44 +00:00
Matt Corallo 7eb5d65bda [IO] Provide a macro which implements `io::Write` for types
With the new `bitcoin_io` library, implementing `io::Write`
manually is somewhat tricky - for `std` users we really want to
provide an `std::io::Write` implementation, however for `no-std`
users we want to implement against our internal trait.

Sadly we cannot provide a blanket implementation of
`std::io::Write` for all types whcih implement our `io::Write`
trait as its an out-of-crate impl.

Instead, we provide a macro which will either implement
`std::io::Write` or our `io::Write` depending on the feature flags
set on `bitcoin_io`.
2023-11-07 05:51:34 +00:00
Matt Corallo 27c7c4e26a Add a `bitcoin_io` crate
In order to support standard (de)serialization of structs, the
`rust-bitcoin` ecosystem uses the standard `std::io::{Read,Write}`
traits. This works great for environments with `std`, however sadly
the `std::io` module has not yet been added to the `core` crate.

Thus, in `no-std`, the `rust-bitcoin` ecosystem has historically
used the `core2` crate to provide copies of the `std::io` module
without any major dependencies. Sadly, its one dependency,
`memchr`, recently broke our MSRV.

Worse, because we didn't want to take on any excess dependencies
for `std` builds, `rust-bitcoin` has had to have
mutually-exclusive `std` and `no-std` builds. This breaks general
assumptions about how features work in Rust, causing substantial
pain for applications far downstream of `rust-bitcoin` crates.

Here, we add a new `bitcoin_io` crate, making it an unconditional
dependency and using its `io` module in the in-repository crates
in place of `std::io` and `core2::io`. As it is not substantial
additional code, the `hashes` io implementations are no longer
feature-gated.

This doesn't actually accomplish anything on its own, only adding
the new crate which still depends on `core2`.
2023-11-07 05:50:42 +00:00
Andrew Poelstra 9b2e1c591a
Merge rust-bitcoin/rust-bitcoin#2165: Use macro to define `sha512::Hash`
71454d438a Use hash_type macro for sha512::Hash (Tobin C. Harding)
d51c1857fd sha512: Move from_engine functions (Tobin C. Harding)

Pull request description:

  This PR does not introduce any logic changes.

  - Patch 1 is a code move.
  - Patch 2 uses the `hash_type!` macro to define the `sha512::Hash` type.

ACKs for top commit:
  Kixunil:
    ACK 71454d438a
  apoelstra:
    ACK 71454d438a

Tree-SHA512: c0148391fbea3602f0c52e5e08883faac6b5cb3f75ae62bfb53b1d2762e28871d349b3d3fb589f59d8bf2912dd63934f8f9a6fe6390afd378e5391eb2c91c237
2023-11-03 21:11:49 +00:00
Tobin C. Harding 0bb537d45b
Move sha512_256 code
Make the `sha512_256` module use similar code layout to the other hash
modules by putting the call to `hash_type` at the top followed by the
`from_engine` function.

Code move only, no other changes.
2023-11-03 10:35:56 +11:00
Tobin C. Harding 71454d438a
Use hash_type macro for sha512::Hash
Currently we are defining the `sha512::Hash` type manually instead of
using the `hash_type` macro.

The generated code using the macro is identical to that without
it (although I didn't actually look at the generated code :)
2023-11-03 10:18:24 +11:00
Tobin C. Harding d51c1857fd
sha512: Move from_engine functions
Make a step towards making the `sha512` module have its code layed out
the same as the rest of the hash modules.

Code move only, no other changes.
2023-11-03 10:14:05 +11:00
Steven Roose 875545517d
Add clippy exceptions for needless_question_mark lint 2023-10-23 16:45:52 +01:00
Andrew Poelstra 2bd1e731b8
Merge rust-bitcoin/rust-bitcoin#2104: Add wasm dev-deps using CI script
685e5101ce Add wasm dev-deps using CI script (Tobin C. Harding)

Pull request description:

  We only test WASM in CI using a stable toolchain however because we have a target specific dev-dependencies section the wasm deps get pulled in during MSRV builds - this breaks the MSRV build.

  Instead of including WASM dev-dependencies in the manifest we can dynamically modify the manifest when running the WASM tests. We do this already to add the `crate-type` section so this is not really that surprising to see in the CI script.

  Doing so allows us to stop pinning the transitive `syn` dependency also which is included in the dependency graph because of `wasm-bingen-test`.

  Originally part of #2093

ACKs for top commit:
  apoelstra:
    ACK 685e5101ce
  sanket1729:
    ACK 685e5101ce. Removing wasm from lock-files is a win

Tree-SHA512: ad607a8a8af329e9830d9284a95a2540bf15a2ceda826b8d1c0312ee094f1f5f54599ee2faa6b611439997c349bdd9a29e6d5ae447bff96a9a538753434e2248
2023-10-06 20:18:32 +00:00
Tobin C. Harding 685e5101ce
Add wasm dev-deps using CI script
We only test WASM in CI using a stable toolchain however because we have
a target specific dev-dependencies section the wasm deps get pulled in
during MSRV builds - this breaks the MSRV build.

Instead of including WASM dev-dependencies in the manifest we can
dynamically modify the manifest when running the WASM tests. We do this
already to add the `crate-type` section so this is not really that
surprising to see in the CI script.

Doing so allows us to stop pinning the transitive `syn` dependency also
which is included in the dependency graph because of `wasm-bingen-test`.
2023-10-05 11:16:24 +11:00
Tobin C. Harding 10374af75c
Make error types uniform
On our way to v1.0.0 we are defining a standard for our error types,
this includes:

- Uses the following derives (unless not possible, usually because of `io::Error`)

  `#[derive(Debug, Clone, PartialEq, Eq)]`

- Has `non_exhaustive` unless we really know we can commit to not adding
  anything.

Furthermore, we are trying to make the codebase easy to read. Error code
is write-once-read-many (well it should be) so if we make all the error
code super uniform the users can flick to an error and quickly see what
it includes. In an effort to achieve this I have made up a style and
over recent times have change much of the error code to that new style,
this PR audits _all_ error types in the code base and enforces the
style, specifically:

- Is layed out: definition, [impl block], Display impl, error::Error impl, From impls
- `error::Error` impl matches on enum even if it returns `None` for all variants
- Display/Error impls import enum variants locally
- match uses *self and `ref e`
- error::Error variants that return `Some` come first, `None` after

Re: non_exhaustive

To make dev and review easier I have added `non_exhaustive` to _every_
error type. We can then remove it error by error as we see fit. This is
because it takes a bit of thinking to do and review where as this patch
should not take much brain power to review.
2023-10-04 15:15:52 +11:00
Tobin C. Harding 34b20dfed1
Remove unused internals dependency 2023-09-22 12:36:00 +10:00
Tobin C. Harding cd47daf13f
hashes: Remove duplicate entry
We accidentally mentioned an error change twice, remove the entry
without the PR link.
2023-09-07 14:19:01 -04:00
Tobin C. Harding e84ca292d9
Clear incorrect implementation of clone warning
Clippy emits:

  error: incorrect implementation of `clone` on a `Copy` type

As suggested use `*self` instead of each individual field.
2023-08-25 12:08:56 +10:00
Tobin C. Harding 53f68383b7
hashes: Bump version to 0.13.0
Add a changelog entry and bump the version to 0.13.0

Does not include changes to `bitcoin` to depend on the new version.
2023-08-24 12:25:42 +10:00
Andrew Poelstra 1b3a9d3580
Merge rust-bitcoin/rust-bitcoin#1990: Introduce the `small-hash` feature for `bitcoin_hashes`
f2c5f19557 Introduce the `small-hash` feature for `bitcoin_hashes` (Alekos Filini)

Pull request description:

  When enabled this feature swaps the hash implementation of sha512, sha256 and ripemd160 for a smaller (but also slower) one.

  On embedded processors (Cortex-M4) it can lead to up to a 52% size reduction, from around 37KiB for just the `process_block` methods of the three hash functions to 17.8KiB.

  The following numbers were collected on `aarch64-unknown-linux-gnu` with `cargo 1.72.0-nightly`.

  ## Original

  ```
  RUSTFLAGS='--cfg=bench -C opt-level=z' cargo bench
  ```

  ```
  test hash160::benches::hash160_10                 ... bench:          33 ns/iter (+/- 1) = 303 MB/s
  test hash160::benches::hash160_1k                 ... bench:       2,953 ns/iter (+/- 187) = 346 MB/s
  test hash160::benches::hash160_64k                ... bench:     188,480 ns/iter (+/- 11,595) = 347 MB/s
  test hmac::benches::hmac_sha256_10                ... bench:          33 ns/iter (+/- 2) = 303 MB/s
  test hmac::benches::hmac_sha256_1k                ... bench:       2,957 ns/iter (+/- 104) = 346 MB/s
  test hmac::benches::hmac_sha256_64k               ... bench:     192,022 ns/iter (+/- 6,407) = 341 MB/s
  test ripemd160::benches::ripemd160_10             ... bench:          25 ns/iter (+/- 1) = 400 MB/s
  test ripemd160::benches::ripemd160_1k             ... bench:       2,288 ns/iter (+/- 93) = 447 MB/s
  test ripemd160::benches::ripemd160_64k            ... bench:     146,823 ns/iter (+/- 1,102) = 446 MB/s
  test sha1::benches::sha1_10                       ... bench:          41 ns/iter (+/- 0) = 243 MB/s
  test sha1::benches::sha1_1k                       ... bench:       3,844 ns/iter (+/- 70) = 266 MB/s
  test sha1::benches::sha1_64k                      ... bench:     245,854 ns/iter (+/- 10,158) = 266 MB/s
  test sha256::benches::sha256_10                   ... bench:          35 ns/iter (+/- 0) = 285 MB/s
  test sha256::benches::sha256_1k                   ... bench:       3,063 ns/iter (+/- 15) = 334 MB/s
  test sha256::benches::sha256_64k                  ... bench:     195,729 ns/iter (+/- 2,880) = 334 MB/s
  test sha256d::benches::sha256d_10                 ... bench:          34 ns/iter (+/- 1) = 294 MB/s
  test sha256d::benches::sha256d_1k                 ... bench:       3,071 ns/iter (+/- 107) = 333 MB/s
  test sha256d::benches::sha256d_64k                ... bench:     188,614 ns/iter (+/- 8,101) = 347 MB/s
  test sha512::benches::sha512_10                   ... bench:          21 ns/iter (+/- 0) = 476 MB/s
  test sha512::benches::sha512_1k                   ... bench:       1,714 ns/iter (+/- 36) = 597 MB/s
  test sha512::benches::sha512_64k                  ... bench:     110,084 ns/iter (+/- 3,637) = 595 MB/s
  test sha512_256::benches::sha512_256_10           ... bench:          22 ns/iter (+/- 1) = 454 MB/s
  test sha512_256::benches::sha512_256_1k           ... bench:       1,822 ns/iter (+/- 70) = 562 MB/s
  test sha512_256::benches::sha512_256_64k          ... bench:     116,231 ns/iter (+/- 4,745) = 563 MB/s
  test siphash24::benches::siphash24_1ki            ... bench:       1,072 ns/iter (+/- 41) = 955 MB/s
  test siphash24::benches::siphash24_1ki_hash       ... bench:       1,102 ns/iter (+/- 42) = 929 MB/s
  test siphash24::benches::siphash24_1ki_hash_u64   ... bench:       1,064 ns/iter (+/- 41) = 962 MB/s
  test siphash24::benches::siphash24_64ki           ... bench:      69,957 ns/iter (+/- 2,712) = 936 MB/
  ```

  ```
  0000000000005872 t _ZN84_$LT$bitcoin_hashes..ripemd160..HashEngine$u20$as$u20$bitcoin_hashes..HashEngine$GT$5input17hc4800746a9da7ff4E
  0000000000007956 t _ZN81_$LT$bitcoin_hashes..sha256..HashEngine$u20$as$u20$bitcoin_hashes..HashEngine$GT$5input17hf49345f65130ce9bE
  0000000000008024 t _ZN14bitcoin_hashes6sha2568Midstate10const_hash17h57317bc8012004b4E.llvm.441255102889972912
  0000000000010528 t _ZN81_$LT$bitcoin_hashes..sha512..HashEngine$u20$as$u20$bitcoin_hashes..HashEngine$GT$5input17h9bc868d4392bd9acE
  ```

  Total size: 32380 bytes

  ## With `small-hash` enabled

  ```
  RUSTFLAGS='--cfg=bench -C opt-level=z' cargo bench --features small-hash
  ```

  ```
  test hash160::benches::hash160_10                 ... bench:          52 ns/iter (+/- 3) = 192 MB/s
  test hash160::benches::hash160_1k                 ... bench:       4,817 ns/iter (+/- 286) = 212 MB/s
  test hash160::benches::hash160_64k                ... bench:     319,572 ns/iter (+/- 11,031) = 205 MB/s
  test hmac::benches::hmac_sha256_10                ... bench:          54 ns/iter (+/- 2) = 185 MB/s
  test hmac::benches::hmac_sha256_1k                ... bench:       4,846 ns/iter (+/- 204) = 211 MB/s
  test hmac::benches::hmac_sha256_64k               ... bench:     319,114 ns/iter (+/- 4,451) = 205 MB/s
  test ripemd160::benches::ripemd160_10             ... bench:          27 ns/iter (+/- 0) = 370 MB/s
  test ripemd160::benches::ripemd160_1k             ... bench:       2,358 ns/iter (+/- 150) = 434 MB/s
  test ripemd160::benches::ripemd160_64k            ... bench:     154,573 ns/iter (+/- 3,954) = 423 MB/s
  test sha1::benches::sha1_10                       ... bench:          41 ns/iter (+/- 1) = 243 MB/s
  test sha1::benches::sha1_1k                       ... bench:       3,700 ns/iter (+/- 243) = 276 MB/s
  test sha1::benches::sha1_64k                      ... bench:     231,039 ns/iter (+/- 13,989) = 283 MB/s
  test sha256::benches::sha256_10                   ... bench:          51 ns/iter (+/- 3) = 196 MB/s
  test sha256::benches::sha256_1k                   ... bench:       4,823 ns/iter (+/- 182) = 212 MB/s
  test sha256::benches::sha256_64k                  ... bench:     299,960 ns/iter (+/- 17,545) = 218 MB/s
  test sha256d::benches::sha256d_10                 ... bench:          52 ns/iter (+/- 2) = 192 MB/s
  test sha256d::benches::sha256d_1k                 ... bench:       4,827 ns/iter (+/- 323) = 212 MB/s
  test sha256d::benches::sha256d_64k                ... bench:     302,844 ns/iter (+/- 15,796) = 216 MB/s
  test sha512::benches::sha512_10                   ... bench:          34 ns/iter (+/- 1) = 294 MB/s
  test sha512::benches::sha512_1k                   ... bench:       3,002 ns/iter (+/- 123) = 341 MB/s
  test sha512::benches::sha512_64k                  ... bench:     189,767 ns/iter (+/- 10,396) = 345 MB/s
  test sha512_256::benches::sha512_256_10           ... bench:          34 ns/iter (+/- 1) = 294 MB/s
  test sha512_256::benches::sha512_256_1k           ... bench:       2,996 ns/iter (+/- 198) = 341 MB/s
  test sha512_256::benches::sha512_256_64k          ... bench:     192,024 ns/iter (+/- 8,181) = 341 MB/s
  test siphash24::benches::siphash24_1ki            ... bench:       1,081 ns/iter (+/- 65) = 947 MB/s
  test siphash24::benches::siphash24_1ki_hash       ... bench:       1,083 ns/iter (+/- 63) = 945 MB/s
  test siphash24::benches::siphash24_1ki_hash_u64   ... bench:       1,084 ns/iter (+/- 63) = 944 MB/s
  test siphash24::benches::siphash24_64ki           ... bench:      67,237 ns/iter (+/- 4,185) = 974 MB/s
  ```

  ```
  0000000000005384 t _ZN81_$LT$bitcoin_hashes..sha256..HashEngine$u20$as$u20$bitcoin_hashes..HashEngine$GT$5input17hae341658cf9b880bE
  0000000000005608 t _ZN14bitcoin_hashes9ripemd16010HashEngine13process_block17h3276b13f1e9feef8E.llvm.13618235596061801146
  0000000000005616 t _ZN14bitcoin_hashes6sha2568Midstate10const_hash17h3e6fbef64c15ee00E.llvm.7326223909590351031
  0000000000005944 t _ZN81_$LT$bitcoin_hashes..sha512..HashEngine$u20$as$u20$bitcoin_hashes..HashEngine$GT$5input17h321a237bfbe5c0bbE
  ```

  Total size: 22552 bytes

  ## Conclusion

  On `aarch64` there's overall a ~30% improvement in size, although ripemd160 doesn't really shrink that much (and its performance also aren't impacted much with only a 6% slowdown). sha512 and sha256 instead are almost 40% slower with `small-hash` enabled.

  I don't have performance numbers for other architectures, but in terms of size there was an even larger improvements on `thumbv7em-none-eabihf`, with a 52% size reduction overall:

  ```
     Size          Crate Name
  25.3KiB bitcoin_hashes <bitcoin_hashes[fe467ef2aa3a1470]::sha512::HashEngine as bitcoin_hashes[fe467ef2aa3a1470]::HashEngine>::input
   6.9KiB bitcoin_hashes <bitcoin_hashes[fe467ef2aa3a1470]::sha256::HashEngine as bitcoin_hashes[fe467ef2aa3a1470]::HashEngine>::input
   4.8KiB bitcoin_hashes <bitcoin_hashes[fe467ef2aa3a1470]::ripemd160::HashEngine as bitcoin_hashes[fe467ef2aa3a1470]::HashEngine>::input
  ```

  vs

  ```
    Size          Crate Name
  9.5KiB bitcoin_hashes <bitcoin_hashes[974bb476ef905797]::sha512::HashEngine as bitcoin_hashes[974bb476ef905797]::HashEngine>::input
  4.5KiB bitcoin_hashes <bitcoin_hashes[974bb476ef905797]::ripemd160::HashEngine>::process_block
  3.8KiB bitcoin_hashes <bitcoin_hashes[974bb476ef905797]::sha256::HashEngine as bitcoin_hashes[974bb476ef905797]::HashEngine>::input
  ```

  I'm assuming this is because on more limited architectures the compiler needs to use more instructions to move data in and out of registers (especially for sha512 which ideally would benefit from 64-bit registers), so reusing the code by moving it into functions saves a lot of those instructions.

  Also note that the `const_hash` method on `sha256` causes the compiler to emit two independent implementations. I haven't looked into the code yet, maybe there's a way to merge them so that the non-const `process_block` calls into the const fn.

  -----

  Note: commits are unverified right now because I don't have the keys available, I will sign them after addressing the review comments.

ACKs for top commit:
  apoelstra:
    ACK f2c5f19557
  tcharding:
    ACK f2c5f19557

Tree-SHA512: 1d5eb56324c458660e2571e8cf59895dc31dae9c5427c7ed36f8a0e81ca2e9a0f39026f56b6803df03635cc8b66aee3bf5182d51ab8972d169d56bcfec33771c
2023-08-17 16:34:10 +00:00
Andrew Poelstra af85528428
Merge rust-bitcoin/rust-bitcoin#1962: Add simd sha256 intrinsics for x86 machines
546c0122d7 Add simd sha256 intrinsics for x86 machines (sanket1729)

Pull request description:

  This is my first time dabbling into architecture specific code and simd. The algorithm is a word to word translation of the C code from  4899efc81d/sha256-x86.c .

  Some benchmarks:

  With simd
  ```
  test sha256::benches::sha256_10                   ... bench:          11 ns/iter (+/- 0) = 909 MB/s
  test sha256::benches::sha256_1k                   ... bench:         712 ns/iter (+/- 2) = 1438 MB/s
  test sha256::benches::sha256_64k                  ... bench:      45,597 ns/iter (+/- 189) = 1437 MB/s
  ```
  Without simd
  ```
  test sha256::benches::sha256_10                   ... bench:          47 ns/iter (+/- 0) = 212 MB/s
  test sha256::benches::sha256_1k                   ... bench:       4,243 ns/iter (+/- 17) = 241 MB/s
  test sha256::benches::sha256_64k                  ... bench:     271,263 ns/iter (+/- 1,610) = 241 MB/s
  ```

ACKs for top commit:
  apoelstra:
    ACK 546c0122d7
  tcharding:
    ACK 546c0122d7

Tree-SHA512: 7167c900b77e63cf38135a3960cf9ac2615f73b2ef7020a12b5cc3f4c047910063ba9045217b9ecfa70f7de1eb0f02f2674f291bd023a853bad2b9162fae831e
2023-08-17 16:22:46 +00:00
Alekos Filini f2c5f19557
Introduce the `small-hash` feature for `bitcoin_hashes`
When enabled this feature swaps the hash implementation of sha512,
sha256 and ripemd160 for a smaller (but also slower) one.

On embedded processors (Cortex-M4) it can lead to up to a 52% size
reduction, from around 37KiB for just the `process_block` methods of the
three hash functions to 17.8KiB.
2023-08-16 14:19:17 +02:00
Riccardo Casatta ff5fa41975
Merge rust-bitcoin/rust-bitcoin#1933: Fix links in docs
154552e334 docs: Do not link to std::option::Option (Tobin C. Harding)
24843468c3 Remove rustdocs links to serde (Tobin C. Harding)

Pull request description:

  Two minor patches to fix up docs links. These were originally done as part of #1880 but are unrelated so pushing them up separately.

ACKs for top commit:
  apoelstra:
    ACK 154552e334
  RCasatta:
    utACK 154552e334

Tree-SHA512: e45e1538c66b59d63a66898896927bb6c1336fb4c8515bb9e2204c8035870ef8e4a6fd32dfc83db2938afda67feb27c48989e382410f9e7ea7a967132941c720
2023-08-02 16:37:13 +02:00
sanket1729 546c0122d7
Add simd sha256 intrinsics for x86 machines 2023-07-27 11:36:08 -07:00
Tobin C. Harding 2268b44911
Depend on hex-conservative
We have just released the `hex-conservative` crate, we can now use it.

Do the following:

- Depend on `hex-conservative` in `bitcoin` and `hashes`
- Re-export `hex-conservative` as `hex` from both crate roots.
- Remove all the old hex code from `hashes`
- Fix all the import statements (makes up the bulk of the lines changed
  in this patch)
2023-07-21 10:59:46 +10:00
Tobin C. Harding 7b402e930c
schemars: Add pinning docs
Not totally necessary but since I went to the trouble of working out the
last working version add it to the docs so the next guy can grep for
`cargo update` to find them.
2023-07-18 10:27:48 +10:00
Tobin C. Harding 5b1443a91c
hashes/embedded: Add script dir and README
To help folk work out how to run the `hashes/embedded` test crate copy
over the `script` directory and an updated version of the `README` from
`embedded/bitcoin`.
2023-07-18 10:27:48 +10:00
Tobin C. Harding 94732aecbf
Add patch section to test crates
In order to keep the embedded and schemacs test crates building when we
update their local transient dependencies we need to use a `patch`
section.

- For `bitcoin/embedded` add `patch` section for `internals`, `hashes`
already has an entry.
- For `hashes/embedded` add `patch` section for `internals`.
- For `hashes/extendend_tests/schemars` add `patch` section for
  `internals`.

FTR for direct local dependencies we use a `path` field when specifying
the dependency.
2023-07-18 10:27:48 +10:00
Tobin C. Harding 512d982275
Remove path field from internals dependency
We use two different methods for specifying local dependencies, `patch`
and also `path`. There does not seem to be a reason why we use both,
lets be uniform. Elect to use `patch` for all local crates.
2023-07-18 10:27:46 +10:00
Andrew Poelstra c7eb9e61ec
Merge rust-bitcoin/rust-bitcoin#1916: internals: Bump version to 0.2.0
8813a63ec9 internals: Bump version to 0.2.0 (Tobin C. Harding)

Pull request description:

  In preparation for release bump the version and add a changelog entry. Includes updating the dependency in `bitcoin` and `hashes`.

ACKs for top commit:
  apoelstra:
    ACK 8813a63ec9
  sanket1729:
    utACK 8813a63ec9

Tree-SHA512: a9bd9d4d69cba21329f3f63a9948afe566bb97c8c65f5d46c329a696a814e9eb31372d378de1ecf0f43f0cb42f11d53dc51bc467223b34629e61315d48b39a29
2023-07-17 16:27:22 +00:00
Tobin C. Harding 71c0043127
Remove docsrs attributes
Somehow when we started using `doc_auto_cfg` we forgot to remove a bunch
of docsrs attributes.
2023-07-14 14:59:11 +10:00
Tobin C. Harding 8813a63ec9
internals: Bump version to 0.2.0
In preparation for release bump the version and add a changelog entry.

Includes updating the dependency in `bitcoin` and `hashes` as well as
the minimal/recent lock files.
2023-07-14 14:31:21 +10:00
Tobin C. Harding c3a99c62ad
CI: Pin serde_json for MSRV build
Recent release of `serde_json` depends on `serde` 1.0.66 but we pin to
1.0.56

Pin `serde_json` for MSRV build to v1.0.99
2023-07-12 15:50:18 +10:00
Tobin C. Harding 24843468c3
Remove rustdocs links to serde
These links are broken just use code ticks instead since `serde` is
feature gated and these docs are private anyways.
2023-07-08 11:29:11 +10:00
Tobin C. Harding 96784b9cfa
Make sha512::HashEngine fields private
Recently we made the hash engine fields pub crate so that `sha512_256`
could construct a hash engine with different constants. We can make the
code slightly cleaner by adding a pub crate constructor and making the
fields private again.

Idea from Kixunil:

  https://github.com/rust-bitcoin/rust-bitcoin/pull/1413#pullrequestreview-1197207593
2023-06-20 10:11:11 +10:00
sanket1729 12e014e288
Merge rust-bitcoin/rust-bitcoin#1878: ci: Remove stal DO_ALLOC_TESTS variable
aa7b3a7d0c ci: Remove stal DO_ALLOC_TESTS variable (Tobin C. Harding)

Pull request description:

  We never enable the `DO_ALLOC_TESTS` variable, and hence never test the "alloc" feature in `hashes`.

  Remove the `DO_ALLOC_TESTS` variable and add "alloc" to the `FEATURES` array.

ACKs for top commit:
  yancyribbens:
    ACK aa7b3a7d0c
  apoelstra:
    ACK aa7b3a7d0c
  sanket1729:
    utACK aa7b3a7d0c

Tree-SHA512: 461735242ec94786624a3653c3ea108d1a8712d5a77943f2ce54b44298624f6d4a43c98a0079782211e9a4b61ac87fbadd9c98608ca0ad82574c4a63b921776f
2023-06-14 17:54:31 -07:00
sanket1729 39dae44d7b
Merge rust-bitcoin/rust-bitcoin#1877: hashes: Remove stale status badge
4dfaec952c hashes: Remove stale status badge (Tobin C. Harding)

Pull request description:

  We do not use travis in our CI pipeline anymore, remove the stale badge.

ACKs for top commit:
  yancyribbens:
    ACK 4dfaec952c
  apoelstra:
    ACK 4dfaec952c
  sanket1729:
    utACK 4dfaec952c

Tree-SHA512: 6865c8cc51f90161ea643922df3bbf890811777e3dcbff9e464d6092f0d79a6ae2798d593f6a27e7f18b05ba66a765c871d4d01086e18b8480916573288afc0e
2023-06-14 17:22:33 -07:00
Andrew Poelstra 80efdb065a
Merge rust-bitcoin/rust-bitcoin#1873: Improve `hashes::Error`
06afd52a12 Improve hashes::Error (Tobin C. Harding)

Pull request description:

  We are trying to make error types stable on the way to v1.0

  The current `hashes::Error` is a "general" enum error type with a single variant, better to use a struct and make the error usecase specific.

  Improve the `hashes::Error` by doing:

  - Make it a struct
  - Rename to `FromSliceError`
  - Move it to the crate root (remove `error` module)

  Includes usage in `bitcoin`.

ACKs for top commit:
  apoelstra:
    ACK 06afd52a12
  Kixunil:
    ACK 06afd52a12

Tree-SHA512: 20a517daaf3e9e09744e2a65cde6e238c8f2d1224899a6c04142a3a4e635d54112b0a2e846d25256071bb27cb70f7482380f98e9a535a5498aa4c7dc0d52cc54
2023-05-29 22:58:17 +00:00
Andrew Poelstra c041aea51a
Merge rust-bitcoin/rust-bitcoin#1876: hashes: Fix stale repository name
3717a549f9 hashes: Fix stale repository name (Tobin C. Harding)

Pull request description:

  The repository name is stale since we moved the `hashes` crate into the `rust-bitcoin` repo a while ago.

ACKs for top commit:
  apoelstra:
    ACK 3717a549f9
  Kixunil:
    ACK 3717a549f9

Tree-SHA512: ac4553547f1912c8242e3b87d3cc8951598999b5512ad1b49494b3c504449939e0e60905d96464b22c71b67ca975d18814a92af6e0aa66ff4f46effb97ac0733
2023-05-29 02:39:42 +00:00
Andrew Poelstra ca06d64455
rename bitcoin-private to bitcoin-internals
Since we now have control over the name on crates.io.
2023-05-26 19:49:52 +00:00
Tobin C. Harding aa7b3a7d0c
ci: Remove stal DO_ALLOC_TESTS variable
We never enable the `DO_ALLOC_TESTS` variable, and hence never test the
"alloc" feature in `hashes`.

Remove the `DO_ALLOC_TESTS` variable and add "alloc" to the `FEATURES`
array.
2023-05-25 18:16:26 +10:00
Tobin C. Harding 4dfaec952c
hashes: Remove stale status badge
We do not use travis in our CI pipeline anymore, remove the stale badge.
2023-05-25 14:34:28 +10:00