-
Notifications
You must be signed in to change notification settings - Fork 174
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
Comments
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). |
Should we complicate things though? If no, let's close this. |
Closed by #1809. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
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?
The text was updated successfully, but these errors were encountered: