Changing votecoin supply assuming all-or-nothing participation

[somnicule]

I've reached a point in developing an Ethereum version of the votecoin system where I'm trying to figure out how to appropriately reward voters for participation. The problem I'm facing is that the ballot and redistribution component only has access to the votecoin addresses and balances for those who voted, making it difficult to penalise non-voters. I could refactor the system such that the ballot can query the full list of addresses, but that seems unnecessarily expensive.

The alternative is to increase the money supply by 1/9th each round, so the relative power of non-voters is reduced by 10%. It seems to work, but I'd appreciate any thoughts on this. Thanks.

[zack]

Increasing the money supply by 10% is a clever trick. I like it.
1.1^(1000)=2.4*(10^41) so after 1000 rounds of voting, the number of votecoins will get super massive and if your computer stores numbers as floating point, we will get rounding errors?

I will try and explain my alternative solution.
My database is a hashtable=DB
Users each have an address. Their address is the key to look up their info. so if my address is 11hn6mHWWEPSag3Du5A8cLSGqKKmnnj
then DB[11hn6mHWWEPSag3Du5A8cLSGqKKmnnj]={'truthcoin':10000, 'count':10, 'votecoin':{'votecoin pool 1':1000, 'votecoin pool 2':25}}
Each pool of votecoins also has an ID. The ID is the key to look up info about that pool.
so DB['votecoin pool 1']={'decisions':{}, jury:{11hn6mHWWEPSag3Du5A8cLSGqKKmnnj:1000, 115Wzzdi5GWurAuJDi4ARXrjHLpk39b:500}}
The tag 'jury' lists everyone and how many votecoins they have. Every time someone sends votecoins, I need to adjust multiple places, but at least everything is O(1)

[psztorc]

Ah, just one of those things you don't think about until you have to code it.

Can you, by default (when the svd-consensus algo finishes), immediately have every owner forced into casting a Ballot of completely blank values. This ballot is then 'updated' (like Bitcoin sequence-number style) when they send coins or cast a new Ballot?

Or is that too complicated?

[zack]

So, if you send votecoins to someone who doesn't own any votecoins, the blockchain needs to create a empty vote for them at the same time.

[somnicule]

I'm currently storing votecoins using ints. As a side note, Ethereum won't support floating-point calculations, and doesn't support fixed-point calculations yet, so there's a fair amount of DIY fixed-point calculation going on at the moment. Ints are stored as 32 byte values, so assuming we start with 10¹⁸ coins, it takes >1400 voting rounds to exceed the amount it's possible to store. With 12 ballots a year, it ends up being about 118 years before it breaks. I expect something else would break the system before we reach that point.

An alternative to avoid this might be to count the last ballot that the user participated in, and updating balances by 0.9^(last ballot run - last ballot participated in) before resetting the missed ballots count to 0. This avoids some of the previously mentioned problems.

I'm not sure how to automatically cast blank ballots and still have the permissions for changing them work out well, so it might be a touch complicated for just getting it running.

[zack]

It seems I was unclear before...
For each pool of votecoins, you should store a list of every person who owns those votecoins, along with how many coins they own.

example: {'zack':100, 'somnicule':200, 'psztorc':100}

If zack sent 1/2  of his votecoins to Bob, you need to update like this:

{'zack':50, 'somnicule':200, 'psztorc':100, 'Bob':50}

[somnicule]

That's more or less how I'm doing things now (the example ethereum currency contracts support that with addresses instead of names) but the problem is that in ethereum there doesn't seem to be an obvious way to loop over the user/balance pairs without already having a list/array of all the user addresses. So you can access the balances for an address iff you have the balance for that address already.  If I'm solving it on the currency side, a solution might be to store balances in a different way. Since the contract storage is just one big array, I could have it so each address links to an index that stores the relevant balance, rather than just the balance itself. This way all relevant info is accessible to the redistribution process.