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

[Karsten Loesing <karsten@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/07/15 15:07, l.m wrote:
> 
>>> 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
> to
>> 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
> what
>> 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.

Good point.  I guess you shouldn't penalize B at all here, because
anyone could set up a family and declare unidirectional family
relations with all or many other relays to have them penalized.  The
only actor you could penalize would be A, because either she's lying
about being in a family with other relays, or she forgot to also
configure the family settings on B correctly.

All in all, doesn't sound too useful to rank down relays because of
that.  Having a notification of some kind would be nice though.

> 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?

I'm coding the "effective_family" field discussed on that ticket.
I'll post a branch once it runs successfully locally (the first
attempt had a bug or two, which is not surprising).  But that doesn't
mean that this code will be merged as is, it's just supposed to be a
better basis for further discussions.  More on the ticket once I have
more to say.

All the best,
Karsten

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJVlWwfAAoJEJD5dJfVqbCryhAIAIVVDsze8vovtA6PPwnuzjNE
sYHjQhyS5G+rV6zRf2gSQSCVzno5aUqh+WTAOWiPyJwmeii43ZZT8IrJ9e+zauxV
6p40slKfKzP/qJjYy+8JCir6ew/3nnjvnKu7cSbVpLBtK1MY/AiX3W+XHMj/eWoR
5Z1yiqN/Wax+stwhUoryThqD1iBWc5HwC7lmwOcwbRof/OGtQhVhgzzAIx88LKof
KvmFCWIn1yvruwTyOmibBreUbzGebxTbnEqzidZ6eM2DQIB6xEoup5lQdZcfVp7K
VFeGf57CzTMj/+nBp37Eux2ZOsVd+5/GyYuekfUqdkh40fGb2sQjf3NNEt/xfN8=
=ayLq
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev