Progress reportI think I should stop writing "another slow week", it's becoming a cliché
The client subscription system basically works. Tested it with quarter of a million subscribed addresses - it's very fast.
--
Now I plan to focus on the
voting system, because I clearly underestimated it.
At first I thought: well, I will just add it later, how difficult could that be? Turns out, pretty difficult
To allow voting with stake we can either:
1. "color" coins
2. or lock them
1. Color coins"Coloring" coins is a bad idea: if somebody buys a large amount of coins to increase his voting power, the last thing he wants is to find out that those coins have already been used in this poll and he now can't vote with them. Also tracking what money participated in what polls is complicated.
2.1. Explicit lockingThis puts a burden on the user to decide what part of his money to use (and lock) in each poll, and on the system to track these locks. Many people will also wait till the last moment to lock their funds, and this can cause abrupt spikes of activity on the last day of voting, hurting system performance.
2.2. Implicit lockingWe could lock the money implicitly by trying to count votes at poll closing time. This is very bad for performance to the point of being infeasible if we want scalability. Plus, you just know that many users will forget that they voted, move or spend money, and then complain that not all their votes counted.
Coin daysWe could try to use coin days for voting, but it's a bad idea too: you can only spend them on one poll at a time. This means you can simply "run out" of your voting power.
It also encourages hoarding and adds another dimension to the problem (time), which complicates things - for example exchanges and other services that hold your money will gain excessive power.
Vote delegationIt would be nice to have the ability to delegate your voting power to representatives, but this opens a whole new can of worms...
--
So you see, it's not that trivial.
http://www.youtube.com/watch?v=IoWJkrlptNs