[tor-dev] tor-roaster.org creates incentives for *non*-proper MyFamily configurations

(since this is not really part of that ticket I'm moving this reply to tor-dev) Replying to [comment:21 virgil][1]: > Re: comment #15 >> 2) there are no incentives for a relay operator to set it properly > > Roster aims to fix this. http://tor-roster.org Quite the opposite I think. tor-roster

Re: [tor-dev] Questions regarding the future of families

> Regarding the state of family support. I've been working on a project > which could be used to expand the number of running relays and have been > trying to find the best way to coordinate this so as to make it both > obvious who the operator is (which can be done with contact info) as well >

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor

On Thu, Mar 3, 2016 at 3:16 PM, Yawning Angel wrote: > On Thu, 3 Mar 2016 16:33:42 + (UTC) > lukep wrote: > > Hi, > > I'm trying to understand the hybrid protocol that's described here. > > The server generates the parallel secret PAR_SEC or P

Re: [tor-dev] Questions regarding the future of families

FWIW, I use MyFamily for what I am assuming Brian uses it for as well, multiple containers across various hosts. On Fri, Mar 4, 2016 at 10:34 AM, Brian "redbeard" Harrington wrote: > For a few months I've been tracking this ticket: > >

[tor-dev] Questions regarding the future of families

For a few months I've been tracking this ticket: https://trac.torproject.org/projects/tor/ticket/6676 Regarding the state of family support. I've been working on a project which could be used to expand the number of running relays and have been trying to find the best way to coordinate this so

Re: [tor-dev] Next version of the algorithm

Hey, > > This algorithm keeps track of the unreachability status for guards > > in state private to the algorithm - this is re-initialized every time > > START is called. > > > > Hmm, didn't we decide to persist the unreachability status over runs, right? > Or not? Yeah, I think we did