[thread reconstructed]
>> On 09/30/2014 06:28 AM, AFO-Admin wrote:
>>> if we would get multithread support, this would boost the bandwith
>>> that is avaible, there i'm sure.
>>> All my relays run in CPU limit because i don't think wasting even more
>>> ipv4 addresses is great, today you get more a
isis:
> Moritz Bartl transcribed 0.5K bytes:
> > Raising the limit from 2 relays per IP to x per IP has been discussed in the
> > past and would be an easy change.
>
> We *still* have that limit? I thought we killed it a long time ago.
>
> Can we kill it now? It's not going to do anything to prev
Moritz Bartl transcribed 0.5K bytes:
> Raising the limit from 2 relays per IP to x per IP has been discussed in the
> past and would be an easy change.
We *still* have that limit? I thought we killed it a long time ago.
Can we kill it now? It's not going to do anything to prevent Sybils, it'll
on
Code! Beautiful code! How I've missed thee!
As mentioned before I'm hip deep in the middle of an arm rewrite. Not only to
overhaul the arm codebase, but to ensure Stem will be up to snuff for a Tor
GUI or web dashboard (projects I'd *love* to jump into someday). I'm delighted
to announce a nice bi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
While working on peer-to-peer hidden services I've been wondering how
long two clients need to wait before arriving at the same view of the
Tor network. The answer, which I find surprising, is that this is
never guaranteed to happen. Here's
On 09/30/2014 06:28 AM, AFO-Admin wrote:
> E.g. you have a Server with 2x E5-2683 v3 v3 and a 10 Gbit/s pipe you
> would need atleast 14 IP's to use most of the CPU.
Multicore support is hard and needs developers. Raising the limit from 2
relays per IP to x per IP has been discussed in the past
On Tue, Sep 30, 2014 at 12:04 AM, isis wrote:
> [1]: I assume that we need replication in Tor's use case. There are papers,
> such as the following:
>
> Kushilevitz, Eyal, and Rafail Ostrovsky.
>"Replication is not needed: Single database, computationally-private
>informa
On Tue, Sep 30, 2014 at 6:29 AM, Prateek Mittal wrote:
>> 4. The *increase* to descriptor size is not well factored in to the
>> analysis.
>>
>> 4.b. All of the Directory Authorities would need to sign each and
>> every
>> descriptor by itself. This would result in the current
>>
Thanks isis. We worked on PIR-Tor a while ago, so my recollection could be
a bit rusty, but here are some thoughts.
1) From a performance perspective, the best results are obtained by using
the information-theoretic variant of PIR-Tor (ITPIR) (as opposed to the
computational variant). As you corre
