mirrors/arti.git/crates/tor-hscrypto/src/pow/v1, branch arti-v1.4.3

squash! Upgrade rand dependency to 0.9.

2025-03-18T16:09:44Z

- The Rng::gen() functions have been renamed to Rng::random().

tor-hscrypto: Add Verifier::seed() helper function.

2024-11-25T18:20:11Z

tor-hscrypto: Add Seed::new.

2024-11-25T18:20:11Z

This includes the ability to generate a seed that does not share a head with the previously used seed, which is generally what we want to do.

tor-netdoc: Support writing pow-params line.

2024-11-25T18:20:11Z

I'm not particularly happy with the code that does the actual writing out of the pow-params line, in particular the error handling there seems very verbose. However, I don't know of a better way to structure it given that APIs I'm working with.

hs-pow: Effort type improvements.

2024-10-09T16:05:21Z

The Effort type didn't have any const constructor and we had to disassemble it to do any arithmetic. This adds a const constructor and int/float saturating arithmetic methods. Co-authored-by: Micah Elizabeth Scott

tor-hscrypto: Fixup broken doc links.

2024-10-09T16:05:21Z

Co-authored-by: Micah Elizabeth Scott

tor-hspow: Big refactor, dissolve this crate

2024-10-09T16:04:35Z

My previous strategy here was to try and centralize hspow in one crate, writing it like a self-contained feature. That introduced friction in the data types, prompting the use of simplistic types at the netdoc/cell layers and full-featured types in the optional modules. This changes tactics, dissolving the low-level parts of tor-hspow into tor-hscrypto and the high-level parts into hsclient/hsservice. Full featured types are used everywhere now, but the tradeoff is that compile-time configurability is a lot more pervasive. Anything that knows about PoW types at all needs to be fully configured out. I took this opportunity to try a more complete set of crate features, allowing users to configure individual PoW schemes. Co-authored-by: Micah Elizabeth Scott