danielle
Pivian
nodeComplex
2
May '17
I would like to make a proposal on how to implement decentralized voting:
2) Abstract the method used to calculate Voting Balance from end users
I think it’s a good idea to abstract the complexity of calculating the voting balance from end users in the wallet since:
a) The algorithm used to calculate it may change
b) This closely mimics proxy statements investors receive and are familar with today. I may own 150,000 shares of XYZ company, but my voting rights might be far less depending on many factors: What class of shares do I own? Am I already vested in those shares? etc.
For transparency’s sake a separate voting balance tab can be created to show how the balance was derived.
3) Time is an important factor
I believe that time is an important factor in calculating the Voting Balance. Vesting is a common concept in public securities, and is adopted by other currencies like NEM’s complex Proof of importance algorithm. It will help reduce an attacker’s ability to quickly gobble up shares in the open market and influence the community’s direction.
Here is a simple example of how that might work (only meant for discussion).
a) PIV held 6 months counts 100% toward voting balance
b) PIV held 3 months counts 50% toward voting balance
c) PIV held less than that counts 25% toward voting balance.
4) Start small, make as few changes as possible to existing governance system
Because I think that the algorithm used to calculate voting balance will be adjusted over time I am in favor of implementing SIMPLE solutions today. Since PIVX was forked from DASH, Masternodes are naturally central to today’s voting process.
a) I suggest we leave that unchanged.
b) To achieve voting for stakers we could consider abstracting the Masternode’s YES-NO decision by one level.
c) Essentially Masternodes will still vote YES-NO. However, their decision to do so will simply governed by the individual votes sent from each wallet proportional to that user’s voting balance. This makes masternodes operate similar to an electoral college.
d) So we will still have a potential for 2200 masternode YES-NO votes, but their vote will simply be slaved to the YES-NO votes sent from wallets weighted by each wallet’s Voting balance.
2
May '17
I would like to make a proposal on how to implement decentralized voting:
- From an end-user perspective I think it is important that they quite simply see:
a) PIV Balance
b) PIV Voting Balance
2) Abstract the method used to calculate Voting Balance from end users
I think it’s a good idea to abstract the complexity of calculating the voting balance from end users in the wallet since:
a) The algorithm used to calculate it may change
b) This closely mimics proxy statements investors receive and are familar with today. I may own 150,000 shares of XYZ company, but my voting rights might be far less depending on many factors: What class of shares do I own? Am I already vested in those shares? etc.
For transparency’s sake a separate voting balance tab can be created to show how the balance was derived.
3) Time is an important factor
I believe that time is an important factor in calculating the Voting Balance. Vesting is a common concept in public securities, and is adopted by other currencies like NEM’s complex Proof of importance algorithm. It will help reduce an attacker’s ability to quickly gobble up shares in the open market and influence the community’s direction.
Here is a simple example of how that might work (only meant for discussion).
a) PIV held 6 months counts 100% toward voting balance
b) PIV held 3 months counts 50% toward voting balance
c) PIV held less than that counts 25% toward voting balance.
4) Start small, make as few changes as possible to existing governance system
Because I think that the algorithm used to calculate voting balance will be adjusted over time I am in favor of implementing SIMPLE solutions today. Since PIVX was forked from DASH, Masternodes are naturally central to today’s voting process.
a) I suggest we leave that unchanged.
b) To achieve voting for stakers we could consider abstracting the Masternode’s YES-NO decision by one level.
c) Essentially Masternodes will still vote YES-NO. However, their decision to do so will simply governed by the individual votes sent from each wallet proportional to that user’s voting balance. This makes masternodes operate similar to an electoral college.
d) So we will still have a potential for 2200 masternode YES-NO votes, but their vote will simply be slaved to the YES-NO votes sent from wallets weighted by each wallet’s Voting balance.