+1
This post is relevant to this discussion:
1 Like
Actually I just read again the initial creon proposal and understood the goal is to make the vote of apathetic voters an average of the previous votes. That’s another thing to do.
I understand now that this proposal actually mixes the 2 ideas: use previous blockchain votes as datafeed to make the apathetic voters vote on average like the active voters.
If the goal is to remove the influence of apathetic voters I think there is a much simpler solution: just let them abstain from voting.
Right now the protocol requires each block to contain a vote. We can easily remove this rule and add an option to let shareholder choose whether they want to vote or not. By default they would not vote. When we count the votes we would take only the blocks that have an actual vote. I think it’d be a cleaner solution than frequency voting.
There are 2 ways to implement it though and shareholders would have to choose one. For example on a vote based on the 2000 past votes, should we take the 2000 past blocks, remove the non-votes and calculate the majority on the remaining actual votes? Or should we take the last 2000 actual votes (that may span over more blocks)?
And about making the votes fuzzy I still think it would be a good thing but the goal is only to protect the privacy of the shareholders, and has nothing to do with apathetic voters.
4 Likes
I like the idea! However, with frequency voting we can vote on multiple data feeds at once eventually (subscribe 40% cryptog, 60% cybnate, for example). Can you think of any way to do that with an abstain vote?
Randomly choosing a data feed among many can be implemented independently (i.e. we can have it without frequency voting nor abstain vote). The most complex part for that is making the GUI.
Doing that would probably be easier to implement than fuzzy voting and may achieve similar results regarding privacy.
1 Like
Thank you @sigmike.
Your solution to remove the influence of apathetic voters seems simpler and better than frequency voting, but in my opinion, does not distinguish between those who actively vote NO by those who have chosen that they want to vote, but actually do not.
I know your time is very limited, but I will venture to ask you one more question:
What is your opinion about Ternary Voting Concept.
1 Like
Indeed, but they would still do that explicitly.
Distinguishing them is feasible but it’s much more complex because we must evaluate abstention per voted item instead of per block. And we must add a way to explicitly vote NO.
It’s somewhat similar to allowing abstention per item, except abstention would be actually counted as NO. The vote results would not actually be changed so I’m not sure it’s worth the effort.
Note that you can already do something similar with custodians: if you vote for an amount of zero to a custodian address that would be an explicit NO.
1 Like
I’m confused why randomly choosing between data feed votes is easier than randomly choosing between a simple boolean. If you can randomly choose between cybnate’s feed and cryptog’s feed, why it be more difficult to implement randomly choosing between 1 and 0?
Just so we’re clear, if I have 80% listed for a motion, the client would write it into the block when it mints 4 out of 5 times. If I have cryptog at 80% and cybnate at 20% and cryptog votes for and cybnate votes against, I again will write the motion into a block 4 out if 5 mints. I fail to see how the first case is more complicated than the second, it seems to me adding a variable linear combination should be more complicated than simply giving a linear combination of 1 and 0 (I.e. a percentage probability of voting).
I was not comparing randomly choosing data feeds with randomly choosing motions. I was comparing it with fuzzy voting which would affect other votes like park rates.
Randomly choosing a data feed would indeed be about the same work as randomly choosing motions. The UI would be more complex for data feeds though.
1 Like
OK, cool, so frequency voting is indeed a precursor to adding a group of datafeeds. P.S. a hundred times thank you for joining the conversation.
1 Like
It’s about the same amount of work but it’s not the same work. Doing one does not really make the other one easier.
Interesting. I’m a little surprised by that. Couldn’t you just take the data feeds and average their % voting for, then input that to the frequency voting function?
What I have in mind when we talk about random data feed selection is just picking randomly the vote from one of the data feeds when a block is found (so that in your example 40% of your blocks would follow cryptog’s data feed, and 60% cybnate’s). It looks like you’re talking about something else.
So If cryptog is voting 50% for motion A and cybnate is voting 100% for motion A and I’m voting 60% on cybnates feed and 40% on cryptog’s feed, I’d vote 70% for motion A.
If cybnate is 100% for and cryptog is 0% for, I’d vote 60% for.
When I say I vote 60% for, that means I write the motion on 3 out of 5 blocks.
Note I could also vote 40% cryptog, 40% cybnate, and 20% block average of last 1000 blocks (which I call ‘default voting’)
I was not thinking about having both frequency voting and multiple data feed. It’s feasible but it’s probably very confusing for the user. If shareholders want that they will have to define precisely how all these systems interact.
Shareholders will have a hard time defining precisely what they want until they see the more basic implementations. This can grow into a smart voting system with incredibly complex rules, such that our blockchain becomes a veritable brain of interacting neurons for our organization. But we need to start somewhere.
Frequency voting supplies a framework that can be built from. By adding a second column to the motion vector representing voting frequencies, we provide a framework whereby we can affect a shareholder’s voting preferences in a continuous way. Whether we’re implementing multiple data feeds, default voting, automated personalized voting, or suggestive voting it would be very useful to have this column. Without it, we are left implementing each one of these features separately. All I’m saying is to combine them all into a single die roll that happens just before the mint is done and let the rest happen on the UI end. That way, all the UI has to send out is that array containing [Motions, Probabilities]. Let’s call this the voter array.
So the first step is to implement the voter array as an advanced option, allowing a switch between the current UI and the UI that Creon suggested.
However, I do appreciate your desire to have a plan of attack before we start implementing things willy nilly. I’ll do my best to outline a plan and get shareholder feedback. @sigmike has been very helpful in outlining what that first step would be like, we should try to define some kind of consensus on what we might use it for.
The next step, in my opinion, would be to implement a check box that autofills the motion box. Ideally, it would also display a message stating that default voting is turned on (basic mode) or grey out the frequency box (advanced mode), and starts default voting on motions. If the checkbox is unchecked it will leave the motions in the box and and either display a message like “All motions are being voted for 100%” (basic mode) or set all frequency percentages to 0% (advanced mode).
Eventually, we would have a UI with something like an advanced voting options tab. In that tab we would allows users to select semi-apathetic rules for linear combinations of data feeds and default voting. We could implement many different concepts here, like a suggested voter array tailored to the individual shareholder’s voting history.
Additional feedback would be helpful, but it will require many more conversations in many more threads. That’s why I am trying to pin this particular thread down to the concept of that first step toward Frequency Voting and the voter array.
I’m not super good at c++ and I don’t have a very good concept of the greater picture of the code, so maybe I’m far off base with this. However, as far as I understand object-oriented programming, we should be able to pass a voter array around to different subroutines to craft votes in an intelligent manner.
2 Likes
Any progress?
I now consider this project low priority and will not revisit hashing the motion until well after B&C is operational.
1 Like
Proposal for implementing motions in Peercoin from @MatthewLM
It is worth to read any single word.
Thank you Matthew.
1 Like
As described, this would make it possible to separate yes votes, no votes and abstentions…
[quote=MatthewLM]A motion might for instance have 450 yes votes, 215 no votes, and 335 abstentions. This would give 45% in favour and 21.5% against.
[/quote]
I wonder if there are any downfalls in the implementation. Thoughts?