On Tue, Sep 22, 2020 at 2:10 PM George Kadianakis wrote:
>
> if you have a GPU-enabled box, so that we can get some benchmarks
> from GPUs as well
>
Someone would have to write a GPU benchmark for that. My code is CPU-only.
>
> tevador do you have the graphing code somewhere
Hi all,
On Mon, Jun 22, 2020 at 4:52 PM George Kadianakis wrote:
> Also, tevador let me know if you'd like me to add you as a co-author on the
> proposal based on all your great feedback so far.
Thanks for the update. Yes, you can add me as a co-author.
> During our performance m
Hi George,
Thanks for the update.
On Wed, Jun 10, 2020 at 2:05 PM George Kadianakis wrote:
>
> Tevador, thanks a lot for your tailored work on equix. This is fantastic.
> I have a question that I don't see addressed in your very well written
> README. In your initial emai
n a certain way, otherwise the solution is invalid.
See: https://github.com/tevador/equix/blob/master/src/equix.c#L14-L23
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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
On Mon, May 18, 2020 at 1:01 PM wrote:
>
> When a cell with a small effort in the queue has any chance of getting
> selected, the optimal strategy for a legitimate client would be to
> compute nonces and send as many nonces as possible until it causes
> congestion on his network. Instead when onl
I've been working on a custom PoW algorithm specifically for this
proposal. It is 10x faster to verify than RandomX-Tor and doesn't
require any memory for verification.
Full write-up is here: https://github.com/tevador/equix/blob/master/devlog.md
Especially the comparison table in th
Hi Mike,
My apologies. I thought this later email from 14th April had the
latest version of the proposal:
https://lists.torproject.org/pipermail/tor-dev/2020-April/014225.html
> In short, we let the queue grow at a faster rate than we serve, and we
> trim it occasionally.
What is the benefit of
Hi teor,
On Sun, May 10, 2020 at 6:36 AM teor wrote:
>
> There are two possible issues with this design:
>
> Division is expensive on some platforms, including ARM-based devices.
> But there might be a way to calculate an approximate value without division.
> (For example, bit shifts, or multiply
On 08 May, 21:53, tevador wrote:
> In particular, the following parameters should be set differently from
> Monero:
>
> RANDOMX_ARGON_SALT = "RandomX-TOR-v1"
>
> The unique RandomX salt means we do not need to use a separate salt as PoW
&
to verify a single hash is around
400-500 μs. A mid-range GPU has a similar performance as a single CPU core.
Most CPUs made since 2011 have similar per-core performance except of low-end
CPUs without hardware AES support.
References:
[REF_BIRTHDAY]: https://en.wikipedia.org/wiki/Birthday_attack#Mathemat
11 matches
Mail list logo
