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

Brainstorming potential improvements to the inbuilt voting mechanism #131

Closed
grctest opened this issue Sep 13, 2016 · 4 comments
Closed

Comments

@grctest
Copy link
Contributor

grctest commented Sep 13, 2016

I attempted to email @gridcoin a couple times but believe I'm being caught in his spam filter, so here's my suggestion regarding how we could improve the inbuilt voting mechanism:

Neuralminer mentioned that he had contacted you (@gridcoin) & informed me that your idea was the following:

"...We should calculate the total interest paid before the startdate of the poll, and reverse engineer the applicable balance from that – and make the balance weight driven from that figure..."

I have a few concerns with the above:

  1. Those with coins in cold storage (not actively staking) may have their balance vote weight negatively affected? We worked out that only 1/3 of total balance is actually staking at any one time (usually), so a large quantity of coins could be in cold storage.
  2. If you were to buy coins off an exchange (to increase your vote weight on an important poll), your coins would not have a total interest paid before the startdate of the poll.

Alternatively to calculating the total interest paid prior to the startdate of the poll, what if we took a page out of Bitcoinocracy's book? https://github.com/arsenische/bitcoinocracy http://bitcoinocracy.com/

With Bitcoinocracy, you sign a message (in our case it would be perhaps "[Poll ID][chosen poll options]") then send the signed message to their web server & if coins move from the address which signed the message then the poll is automatically adjusted to not include the moved coins. Instead of sending the message to a centralized server, perhaps we could send it as an OP_Return message or to a burn address that clients monitor?

An immediate difficulty with the bitcoinocracy approach would be that since we're a POS crypto many users have their coins split across multiple addresses (users would perhaps need to send multiple vote transactions, or sign the vote with all addresses or send their coins to the one address).

Just brainstorming all possible voting options - best to have multiple ideas, eh?

Does anyone else have voting mechanism improvement suggestions?

@grctest
Copy link
Contributor Author

grctest commented Oct 14, 2016

Just encountered a new issue - long existing investor client just added a new CPID (begun crunching for heating again), now unable to vote in mag+balance polls because my cpid age is less than the poll length (despite investor mode being constant for months).

@denravonska
Copy link
Member

Should we complicate things though? If no, let's close this.

@RoboticMind
Copy link
Contributor

@jamescowens
Copy link
Member

Closed by #1809.

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

No branches or pull requests

4 participants