Sebastian Hahn:
>
> On 27 Sep 2014, at 02:18, Mike Perry wrote:
> > If we were willing to tolerate 10% directory overhead this would allow
> > for 5 times as many users. In other words, 100M daily connecting users.
> >
> > We would still need to find some way to fund the growth of the network
>
30.09.2014, 01:12 isis:
> isis [mash-up]
>
> [3]: Please, don't give all the shit relays to me as bridges. I think it's
> less important scalability-wise (right now) to have a strict cutoff rate
> for bridges, but eventually, when/if we ever have Bridge Bandwidth
> Authorities, Brid
[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
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
Andrew Lewman transcribed 1.8K bytes:
> The last research paper I see directly addressing scalability is Torsk
> (http://www.freehaven.net/anonbib/bibtex.html#ccs09-torsk) or PIR-Tor
> (http://www.freehaven.net/anonbib/bibtex.html#usenix11-pirtor)
Using Private Information Retrieval (PIR) to retr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
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 and more cpu cores that is
not lini
On Mon, Sep 29, 2014 at 7:12 PM, Ryan Carboni wrote:
> You're missing the point. It would be trivial for a multibillion dollar
> organization to sybil attack Tor if you add excessive restrictions.
If you look at the numbers isis posted, all relays below the median
contribute less than 3% of the o
It would be trivial for a multimillion dollar organisation to sybil
attack Tor even as it stands right now.
On 30/09/2014 01:12, Ryan Carboni wrote:
> On Mon, Sep 29, 2014 at 4:36 PM, isis wrote:
>
>> Ryan Carboni transcribed 1.1K bytes:
>>> There's one issue if you remove all the small relays,
On Mon, Sep 29, 2014 at 4:36 PM, isis wrote:
> Ryan Carboni transcribed 1.1K bytes:
> > There's one issue if you remove all the small relays, only relays run by
> > the NSA will be around. Not many people have access to multi-megabit
> upload
> > speeds. And those that do might also be using bitt
Ryan Carboni transcribed 1.1K bytes:
> There's one issue if you remove all the small relays, only relays run by
> the NSA will be around. Not many people have access to multi-megabit upload
> speeds. And those that do might also be using bittorrent.
I'm quite certain that I'm definitely not the NS
isis transcribed 14K bytes:
> [...]
Oopsie daisies. Forgot my footnotes and references! Voilá:
[0]: https://www.torproject.org/docs/tor-relay-debian.html.en
[1]:
https://metrics.torproject.org/bandwidth.html?graph=dirbytes&start=2014-06-27&end=2014-09-25#dirbytes
[2]:
https://metrics.torproject
Griffin Boyce transcribed 2.7K bytes:
> I'd say that the idea to 'downgrade' people into being bridges is a good
> one, if done without requiring user input. 'Everyone run a relay' might
> only be useful because so many of the people we say it to have fast
> connections. It seems reasonable to
Mike Perry transcribed 9.3K bytes:
> Andrew Lewman:
> > I had a conversation with a vendor yesterday. They are
> > interested in including Tor as their "private browsing mode" and
> > basically shipping a re-branded tor browser which lets people toggle the
> > connectivity to the Tor network on and
I'd say that the idea to 'downgrade' people into being bridges is a
good one, if done without requiring user input. 'Everyone run a relay'
might only be useful because so many of the people we say it to have
fast connections. It seems reasonable to filter out persistently low
connections (a
There's one issue if you remove all the small relays, only relays run by
the NSA will be around. Not many people have access to multi-megabit upload
speeds. And those that do might also be using bittorrent.
___
tor-dev mailing list
tor-dev@lists.torprojec
On 28 Sep 2014, at 16:33, Tom Ritter wrote:
> On 28 September 2014 07:00, Sebastian Hahn wrote:
>> This analysis doesn't make much sense, I'm afraid. We use compression
>> on the wire, so repeating flags as human-readable strings has a much
>> lower overhead than you estimate, for example. Re-do
On 28 September 2014 07:00, Sebastian Hahn wrote:
> This analysis doesn't make much sense, I'm afraid. We use compression
> on the wire, so repeating flags as human-readable strings has a much
> lower overhead than you estimate, for example. Re-doing your estimates
> with actually compressed conse
On 27 Sep 2014, at 10:18 , tor-dev-requ...@lists.torproject.org wrote:
> Date: Fri, 26 Sep 2014 17:18:07 -0700
> From: Mike Perry
> To: tor-dev@lists.torproject.org
> Subject: Re: [tor-dev] Scaling tor for a global population
>
> 2. Cut off relays below the median capacity,
On 28 Sep 2014, at 02:12, Tom Ritter wrote:
> why not also change the consensus
> and related document formats to be something more efficient than ASCII
> text? Taking the latest consensus and doing some rough estimates, I
> found the following:
>
> Original consensus, xz-ed: 407K
> Change flag
Mike Perry:
> 5. Invest in the Tor network.
>
>Based purely on extrapolating from the Noisebridge relays, we could
>add ~300 relays, and double the network capacity for $3M/yr, or about $1
>per user per year (based on the user counts from:
>https://metrics.torproject.org/users.html
M. Ziebell:
> Besides the fact that this could be a great opportunity for tor in many
> ways I see two problems we should consider:
>
> - this vastly growth would be "artificial". What happens to all the
> users and servers if they stop supporting the product or close-down?
In this case, presum
Fabio Pietrosanti (naif):
> Il 9/27/14, 2:33 AM, Mike Perry ha scritto:
> >
> > We could also handle controlled rollouts to fractions of their userbase
> > to test the waters, and slowly add high capacity nodes to the network to
> > support these new users, to ensure we have the people ready to acc
>
> But, because this is fraction rises with both D and U, these research
> papers rightly point out that you can't keep adding relays *and* users
> and expect Tor to scale.
Broadcast a fraction of all available directories? Use md5 as a random
number generator, hash the ECC/RSA keys using md5. A
On 26 September 2014 22:28, Mike Perry wrote:
> That's basically what I'm arguing: We can increase the capacity of the
> network by reducing directory waste but adding more high capacity relays
> to replace this waste, causing the overall directory to be the same
> size, but with more capacity.
I
Besides the fact that this could be a great opportunity for tor in many
ways I see two problems we should consider:
- this vastly growth would be "artificial". What happens to all the
users and servers if they stop supporting the product or close-down?
- IMHO it is a problem if the network exp
Il 9/27/14, 2:33 AM, Mike Perry ha scritto:
>
> We could also handle controlled rollouts to fractions of their userbase
> to test the waters, and slowly add high capacity nodes to the network to
> support these new users, to ensure we have the people ready to accept
> payment for running the server
To avoid squashing the Tor network with all of these new clients, the
company would almost certainly have to run some big relays to help
compensate for the additional load. Another proposal would be some sort of
incentive for running relays.
-V
___
tor-
Mike Perry:
> Andrew Lewman:
> > I had a conversation with a vendor yesterday. They are
> > interested in including Tor as their "private browsing mode" and
> > basically shipping a re-branded tor browser which lets people toggle the
> > connectivity to the Tor network on and off.
> >
> > They ver
On 27 Sep 2014, at 02:18, Mike Perry wrote:
> If we were willing to tolerate 10% directory overhead this would allow
> for 5 times as many users. In other words, 100M daily connecting users.
>
> We would still need to find some way to fund the growth of the network
> to support this 40X increase
Fabio Pietrosanti (naif):
> Il 9/26/14, 4:58 PM, Andrew Lewman ha scritto:
> > They very much like Tor Browser and would like to ship it to their
> > customer base. Their product is 10-20% of the global market, this is of
> > roughly 2.8 billion global Internet users.
> . WOW! .
Presumably
Andrew Lewman:
> I had a conversation with a vendor yesterday. They are
> interested in including Tor as their "private browsing mode" and
> basically shipping a re-branded tor browser which lets people toggle the
> connectivity to the Tor network on and off.
>
> They very much like Tor Browser an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think one of the important thoughts here, at least as an exit
operator is that having a large group like that can significantly
influence how Tor is seen and I am sure having that kind of backing
could open many avenues for us.
If we are to scale up
Il 9/26/14, 4:58 PM, Andrew Lewman ha scritto:
> They very much like Tor Browser and would like to ship it to their
> customer base. Their product is 10-20% of the global market, this is of
> roughly 2.8 billion global Internet users.
. WOW! .
>
> Is there a better list available for someon
I had a conversation with a vendor yesterday. They are
interested in including Tor as their "private browsing mode" and
basically shipping a re-branded tor browser which lets people toggle the
connectivity to the Tor network on and off.
They very much like Tor Browser and would like to ship it to
39 matches
Mail list logo
