demexp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Demexp-dev] A simple path for delegation


From: Felix HENRY
Subject: Re: [Demexp-dev] A simple path for delegation
Date: Fri, 12 Jan 2007 15:41:01 +0100



On 1/12/07, David MENTRE <address@hidden> wrote:
Hello Jérémy,

2007/1/12, Jeremy Dubreil <address@hidden>:
> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]