"Magnitude+Balance" Voting weight balance

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

[grctest]

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]

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]

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]

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]

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

[grctest]

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.

[jring-o]

time to change back to 50/50

[iFoggz]

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

[TheCharlatan]

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

[jring-o]

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.

[jamescowens]

I am closing this here. It belongs in Gridcoin-Tasks if we want to discuss it again.