On 1/12/07, David MENTRE <[EMAIL PROTECTED]> wrote:
Hello Jérémy, 2007/1/12, Jeremy Dubreil <[EMAIL PROTECTED]>: > In some cases this might lead to something we would wish to avoid. > Indeed, if a voter A tries to delegate the question Q to the other > participants then he can infer who is on a path of delegation to him. > And in the same time he can find out who is not delegating to him > whenever the delegation is accepted. Also, A communicating with some > other participants can more information about the delegation graph.
That's true, but I would say: so what? Is it really a problem to get some knowledge about who is not delegating to you? Of course ideally one would prefer not to know but I see no strong objection from a secruity / vote pressure point of view (it doesn't mean there aren't). That's a good question. I haven't thought about those kind of issues.
Delegation is much more complicated than I thought, even for this "simple" case. ;-)
Then I suggest another approach, but first I need to know something. Currently (in demexp 0.8), when someone votes, I assume that a matrix is incremented, analyzed, and the winner is output. However, is it complex to recompute the matrix from scratch? Let us assume it is not too complex. Then a new procedure for delegation could be the following: -When someone choses a delegate, follow the chain and check for loops. If no loop, then ok. -When computing the vote of someone, simply follow the delegation chain to get the vote. -everytime someone votes (or changes his vote), recompute the whole matrix (this is needed because we don't know who is delegating to him) -everytime someone delegates (or changes his delegation), recompute the whole matrix (needed for the same reason) I think we should not be afraid of recomputing all the votes on the server. If using computation power allows us to simplify development, let's use it at this stage of the project. And computation power is cheap compared to developper's spare time! I make here another proposal to simplify things (this would be a big change as compared to our previous plans) "If you accept to be a delegate on a certain subject/question, then you are not allowed to delegate this question/subject to anyone else" I understand this is quite restrictive but : -it is not completely absurd (one trusts the person's opinion but not necessarily the person at the end of his delegation chain). -it GREATLY simplifies implementation: no delegation loop checking required -it removes the "delegation ice age" problem: I've been thinking about this problem lately: if demexp is deployed on wide scale and there are delegations all around the place, then chance of loops occuring are growing exponentially. Each time you change a delegation, you increase the risk of being refused because of loops creations. This leads to a frozen situation (hence the name) where it is very difficult for people who recieve a lot of delegations to change there delegates because their will create loops with themselves all the time. Please feel free to object/discuss/elaborate on this, Felix
_______________________________________________ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev