f40255cb95
The solve tests are all tunable so that we can balance execution time with test coverage. A longer solve will test more random programs and it will test more of the nonce increment function, minor benefits at the cost of much more CPU. The starting nonce in solve_effort1k_aa_41_01 was set so that we would exercise a rollover in bit 7 of the nonce increment before the full width rollover, but this wasn't a particularly helpful place to test and certainly not worth the 13+ seconds it takes on my machine. This patch bumps the starting nonce to a value much closer to the target, and still including the full-width rollover. Brings solve_effort1k_aa_41_01 down from 13.2 seconds to 0.5 sec for me. For ticket #991 Signed-off-by: Micah Elizabeth Scott <beth@torproject.org> |
||
---|---|---|
.. | ||
src | ||
tests | ||
Cargo.toml | ||
README.md |
README.md
tor-hspow
Tor supports optional proof-of-work client puzzles, for mitigating denial of service attacks on onion services. This crate implements the specific puzzle algorithms we use, and infrastructure for solving puzzles asynchronously.
Proposal 327 introduced our first algorithm variant, named v1
.
It is based on the Equi-X asymmetric puzzle and an adjustable effort check
using a Blake2b hash of the proof. The underlying algorithm is provided by
the [equix
] crate.
EXPERIMENTAL DRAFT
Just here as a proof-of-concept and to test the algorithms. None of the API here is final, the current status is that lower layers are exposed unnecessarily and upper layers are unwritten.
For Tor client puzzle support in Arti. (#889)