specs: what happens with decisions if reputation distribution changes?

[jellegerbrandy]

Reputation distribution changes in time; the decision process takes time. This raises a number of decisions we need to make on how to count votes (i.e. relative to which distribution): Here is a typical case:

• Ann has 55% of the reputation, Bill has 45%.
• Ann votes "yes".
• Reputation distribution changes: Bill now has 60%, Ann has 40%.
• Bill votes "no"

Question: did the proposal pass? And specifically: how much rep is staked on "yes" and how much on "no"?

[fmatan]

Two things:

1. we still need to decide about the actual voting-collection method: we have a default one for now but should consider others. There's a few posts on this topic (including of people from Colony), reviewing different methods and problems. Basically you can compute votes all together, or one by one, etc.

2. One thing is clear: we need to use everyone's reputation from the same reputation distribution (ie. the reputation distribution at the same time). So if we'd to collect votes one by one, we'd probably like to consider their reputation at the time of the first vote (or the making of proposal), etc. Otherwise we'd not sum them into 100%, and would also be exposed to more kinds of attack.

[jellegerbrandy]

I moved your first point to a new issue, #21 .

Regarding the second point. We sort of need to tally the votes at the moment they are cast, because tallying them all together is difficult to do because of gas limits. And as you said, we also want a sort of consistent vote (summing to 100%, for example).

So it seems that the only option is to tally the votes on the basis of a reputation distribution "snapshot" taken, say, at the time the proposal is submitted.

This seems reasonable to me. Next task: finding out how to do this in solidity.

[jellegerbrandy]

It seems we cannot do this in the EVM without expliciting storing the state of the reputation distribution: http://ethereum.stackexchange.com/questions/11545/is-it-possible-to-access-storage-history-from-a-contract-in-solidity

So this is a problem, especially because our reputation contract is expected to become quite large.

There are many solutions I can think of, but at the end, it means that we would need to pay for storing the whole history of the reputation contract, which seems excessive.