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