> The client's algorithm:
> Input: C
>
> 1. Select N, E
>
> 2. Calculate S = equix_solve(C || N || E)
>
> 3. Calculate R = blake2b(C || N || E || S)
>
> 4. if R * E > UINT32_MAX, go back to step 1)
>
> 5. Submit C, N, E, S (68 bytes total)
It looks like all the 40320 permutations of the 16-bi
> Sending many requests is not the optimal strategy. One high-effort
> request would have exactly the same chance of being selected as many
> low-effort requests with the same total effort. The difference is that
> with many requests, the client wouldn't know which rendezvous would be
> selected, s
> What is the benefit of this approach rather than discarding low
> priority requests right away in the top-half handler?
>
> Note that a priority queue is typically implemented as a heap, which
> does not support efficient trimming.
Correct me if I'm wrong.
When a cell with a small effort in t
