Skip to content

"Magnitude+Balance" Voting weight balance #87

Description

@grctest

Original thread: https://cryptocointalk.com/topic/40773-discussion-magnitudebalance-voting-type-magnitude-weight-unbalanced/

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).

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?
  • 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? Past discussion hit a wall, we couldn't figure out any other solutions.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions