What is this 'Magnitude + Balance' voting weight?
Currently, the voting weight category used most often for polls is the 'mag+balance' voting type.
The current balance between TotalMag (mag) & TotalCoinSupply (balance) is equal (i.e. TotalMag == TotalCoinSupply).
Original thread.
Gridcoin repo github issue.
Top noteworthy magnitude voting weights
- According to Gridresearchcorp, the top 10 users currently have a combined magnitude of 33669 out of a total 115000 mag. (33669/115000)*376,287,674 = 110,167,214.75 GRC
- The pool has a current voting weight of (10,496/115000)*376,287,674 = 34,343,612.40 GRC
- The top 3 individuals (after the pool) have a weight of (14222/115000)*376,287,674 = 46,535,333.04 GRC.
Issues this raises
- With voting participation in foundation expenses being low (especially for advertisements), those with high magnitude could potentially push through self-benefiting expenses.
- With the current generation (3rd gen) BOINC credit system being open to manipulation, an attacker could potentailly fraudulently achieve a high mag in order to receive a massive voting weight (To disrupt, or defraud the voting mechanism). We can kick cheaters, but detecting fraudulent activity will prove difficult & time consuming.
- A non-fraudulent (legit research/crunching) attacker only needs to crunch for a month in order to achieve full voting weight potential.
- Pools in the future may pose an increasingly greater centralization risk. Whilst Katiee's pool is trusted and the only pool at the moment, more pools will be created in the future & they may vote with users combined magnitude (with or without consent). Individual CPIDs are capped to 20k, but a pool could simply create a second CPID for their users to crunch under.
- A pool is a significantly cheaper method of achieving a high mag than crunching projects with a server farm. If you offered 0% fees in return for granting full consent to vote on users behalf you'd have a lot of users taking up such an offer.
- Conflicting values are being assigned to magnitude. In the release schedule, 1,344,000 to 1,488,000 GRC are issued on a monthly basis, yet a months proven computation (RAC) is being allocated the equivalent of 252.88 to 280 months worth of voting weight? (total supply/months issuance).
- Assigning an equal weight to magnitude as balance undermines the value & security of balance; users are less likely to hold onto minted coins when they know that a high mag can maintain their projects whitelist status.
Past proposals by users
- Factor time users have been crunching (blocks since advertised beacon) into the magnitude voting weight, as a form of trust/verification? Variable for all users, complicated to enforce.
- Rebalance magnitude to be equal to 6 months GRC earnings. This will provide magnitude 2.23% voting weight compared to balance's 97.77%.
- Rebalance magnitude to be equal to 12 months GRC earnings. This will provide magnitude 4.36% voting weight compared to balance's 95.6%.
- Rebalance voting weights so that balance has 70% weight, and magnitude has 30% weight.
- Rebalance magnitude to be equal to one months maximum issued GRC (since RAC is only a 30 day calculation).
- Ban Pool CPIDs from voting (IMO not appropriate/enforceable & a slippery slope - some pools may implement voting within their website to reflect their users opinion).
Thoughts on a solution to this voting weight balance topic?
Best regards,
CM.
