On Mon, Jun 8, 2020 at 3:09 AM wrote:
>
> It looks like all the 40320 permutations of the 16-bit words in S are
> equix solutions. Are steps 3 to 5 supposed to be repeated for all the
> permutations?
>
Each unique S provides only one attempt. The indices in S must be
ordered in a certain way, ot
> 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
Hi Patrick,
> 553 Unable to store creds for
Did you set ClientOnionAuthDir in torrc (to a directory with "private
enough" permissions)?
Rusty
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists
> 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
On Sun, Jun 7, 2020 at 8:42 AM wrote:
>
> One way is to include the target effort in requests, and include both
> the server-provided nonce and the target effort as the x in Hx. Then
> only check that the real effort comes out no less than the target
> effort, but use the target effort for everyt
