[tor-dev] Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth

l.m ter.one.leeboi at hush.com
Thu Jul 2 13:07:04 UTC 2015

>> One proposal I've liked is to socially discourage asymmetrical
>> families by giving them with bad badges on Roster.  If A says B is
>> part of their family but B doesn't reciprocate, A gets a penalty to
>> their bandwidth points.

> Maybe don't go as far as penalizing relay operators for attempting
> configure a relay family and not succeeding at it.  Keeping family
> configurations updated is not exactly trivial.  And if the effect is
> that relay operators stop configuring families at all, that's not
> we wanted, either.

> It would be good to point out configuration problems with family
> settings and help operators debug them easily.

If my understanding of this is correct, doesn't this also have
problems with proof-of-operator? That is, exactly as the current case,
there's no inherently reliable way to prove that if A declares B and B
doesn't declare A, that there *should* be a bi-directional relation.
Other properties of a node/relay only go so far in proof-of-relation.
The existence of a bi-directional relation is only taken as a hint for
path selection. Given X and Y are chosen and have a bi-directional
relation, discard one based on the first chosen.

> I started implementing something here and will report back on the
> ticket as soon as I'm more convinced that it works.

No hints?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150702/511e51ad/attachment.html>

More information about the tor-dev mailing list