Re: [tor-dev] Tor proposals implemented in Tor 0.2.3.x

2012-07-01 Thread Ian Goldberg
On Sun, Jul 01, 2012 at 07:06:29PM +0200, Fabian Keil wrote: > I implemented (partial) optimistic data support for Privoxy about a year > ago. The code hasn't been committed to the official repository due to the > documentation challenge outlined above. Fair enough. It turns out it never hurts to

Re: [tor-dev] Tor proposals implemented in Tor 0.2.3.x

2012-07-01 Thread Fabian Keil
Ian Goldberg wrote: > On Sun, Jul 01, 2012 at 05:29:04PM +0200, Fabian Keil wrote: > > > So if only a handful of clients > > > have upgraded to a TBB that supports it (none does at this time), > > > they'll stand out. That's why the default is "use the conse

Re: [tor-dev] Tor proposals implemented in Tor 0.2.3.x

2012-07-01 Thread Ian Goldberg
On Sun, Jul 01, 2012 at 05:29:04PM +0200, Fabian Keil wrote: > > So if only a handful of clients > > have upgraded to a TBB that supports it (none does at this time), > > they'll stand out. That's why the default is "use the consensus value", > > which is curr

Re: [tor-dev] Tor proposals implemented in Tor 0.2.3.x

2012-07-01 Thread Fabian Keil
Ian Goldberg wrote: > On Sat, Jun 30, 2012 at 07:03:19PM +0200, Fabian Keil wrote: > > Nick Mathewson wrote: > > > > > IMPLEMENTED IN 0.2.3.x > > > > >174 Optimistic Data for Tor: Server Side > > >181 Optimistic Data for Tor: Client Side > > > > > > This one is a performance ha

Re: [tor-dev] Open Proposals as of June 2012

2012-07-01 Thread Fabio Pietrosanti (naif)
On 6/19/12 2:30 AM, Jacob Appelbaum wrote: >>146 Add new flag to reflect long-term stability >> >> From time to time we get the idea of having clients ship with a >> reasonably recent consensus (or a list of directory mirrors), >> so instead of bootstrapping from one of the auth

Re: [tor-dev] Tor proposals implemented in Tor 0.2.3.x

2012-07-01 Thread Fabio Pietrosanti (naif)
On 6/18/12 11:24 PM, Nick Mathewson wrote: > PARTIALLY IMPLEMENTED IN 0.2.3.x > >186 Multiple addresses for one OR or bridge > > We've implemented this to the extent of letting a bridge have a > single IPv6 address. Supporting this for regular relays will > need to wait for 0