Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Magnitude+Balance" Voting weight balance #87

Open
grctest opened this issue May 20, 2016 · 10 comments
Open

"Magnitude+Balance" Voting weight balance #87

grctest opened this issue May 20, 2016 · 10 comments

Comments

@grctest
Copy link
Contributor

@grctest grctest commented May 20, 2016

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.

@grctest
Copy link
Contributor Author

@grctest grctest commented Jul 19, 2016

https://github.com/gridcoin/Gridcoin-Research/blob/7167d32d9c7dd6da66e1ca671524d4f838830fb2/src/rpcblockchain.cpp#L2804
double dmag = structMag.Magnitude;

https://github.com/gridcoin/Gridcoin-Research/blob/7167d32d9c7dd6da66e1ca671524d4f838830fb2/src/rpcblockchain.cpp#L2851
+ "</BALANCE><MAGNITUDE>" + RoundToString(dmag,0) + "</MAGNITUDE>";

Proposed new weight:
double dmag_weight = ((dmag + 0.001)/115000)*1440000;
+ "</BALANCE><MAGNITUDE>" + RoundToString(dmag_weight,0) + "</MAGNITUDE>";

(0.001 added to catch dmag=0, could instead catch it with another if statement here: https://github.com/gridcoin/Gridcoin-Research/blob/7167d32d9c7dd6da66e1ca671524d4f838830fb2/src/rpcblockchain.cpp#L2846)

@grctest
Copy link
Contributor Author

@grctest grctest commented Sep 2, 2016

I'm going to create a couple Gridcoin polls asking the Gridcoin community what an appropriate balance between mag+balance is.

Multiple vote types will be used (balance only and magnitude only polls)

EDIT: https://steemit.com/gridcoin/@cm-steem/gridcoin-polls-what-should-we-rebalance-the-mag-balance-vote-weight-to

Please vote!

@grctest
Copy link
Contributor Author

@grctest grctest commented Oct 9, 2016

We held the vote and investors voted 90:10, crunchers voted 70:30.

Thoughts on mag+balance magnitude? Take the average of the two?

@grctest
Copy link
Contributor Author

@grctest grctest commented Oct 15, 2016

The average between the two is 5.67:1 balance:mag, resulting in 67,020,000 vote weight for totalmag.

Though, voting participation is still incredibly low, we could potentially run this poll again if we are able to rally more users to vote..

@gridcoin
Copy link
Contributor

@gridcoin gridcoin commented Nov 7, 2016

Ok, I added the 5.67:1 to the code, will be in the next release.

@grctest
Copy link
Contributor Author

@grctest grctest commented Nov 21, 2016

Hey,

Thanks for looking into this issue.

Release: https://github.com/gridcoin/Gridcoin-Research/releases/tag/3.5.8.3

Location of code update:
https://github.com/gridcoin/Gridcoin-Research/blob/957ab56caf4d007c2b03c6d502bce2b38bab86f4/src/rpcblockchain.cpp#L4203

MoneySupplyFactor code: https://github.com/gridcoin/Gridcoin-Research/blob/957ab56caf4d007c2b03c6d502bce2b38bab86f4/src/rpcblockchain.cpp#L4176

double Factor = (MoneySupply/TotalNetworkMagnitude+.01);

So the max that Factor can be is (382938149/115000)=3329.89

So, putting that into the following

Before:

double UserWeightedMagnitude = MoneySupplyFactor*magnitude;
UserWeightedMagnitude=3329.89*115000
UserWeightedMagnitude=382938149

After:

double UserWeightedMagnitude = (MoneySupplyFactor/5.67) * magnitude;
UserWeightedMagnitude = (3329.89/5.67) * 115000;
UserWeightedMagnitude = 67537451.499118166

Cool, let's close this issue then.

@grctest grctest closed this Nov 21, 2016
@jring-o
Copy link

@jring-o jring-o commented Dec 2, 2017

time to change back to 50/50

@iFoggz
Copy link
Member

@iFoggz iFoggz commented Dec 2, 2017

changing back to 50/50 would make researchers voting weight less.

@TheCharlatan
Copy link
Collaborator

@TheCharlatan TheCharlatan commented Apr 20, 2018

The current formula seems a bit unintuitive. From what I can gather the vote weight is calculated with:

TotalMoneySupply/TotalNetworkMagnitude * UserMagnitude/5.67 + UserBalance

It would probably make much more sense to use

UserMagnitude/TotalNetworkMagnitude * 1/5.67 + UserBalance/TotalMoneySupply
@denravonska denravonska reopened this Apr 20, 2018
@jring-o
Copy link

@jring-o jring-o commented Apr 20, 2018

to clarify my comment:

currently, total magnitude vote-weight = ~1/5th of total balance vote-weight

i think they should be more balanced, or that:

total magnitude vote-weight = total balance vote-weight

this would encourage proposals to benefit both those who hold a large balance and those who contribute large magnitudes. currently, a proposal that benefits balance holders while hurting crunchers can pass through the agreement of balance holders alone.

consider that many crunchers might not hold GRC -- they may crunch -> receive -> sell.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.