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?
Adding a distinction between not votes and abstentions could indeed be useful for Nu, though the issue as I see it would be how to interpret the results. At the moment motions are passed when there are 50% or more votes (blocks and share days) for it, but how would you measure a pass when there are votes against? One suggestion could be to use the no votes as a type of veto to prevent too much disapproval. If the yes votes reach over 50% but there are more than say 10% explicit no votes, then the motion cannot be passed unless the no votes fall below 10% and the yes votes remain over 50%.
In my Peercoin proposal the votes are intended to be informational only. Iâve not proposed any strict objective circumstances by which a motion is passed. But Nu would continue to require an objective decision upon which all shareholders can agree that a motion has passed or not.
3 Likes
"Now; do you want to have to explicitly vote against every one of those proposals you disagree with every time they are made? No, of course you donât, and you shouldnât be trying to force others to have to explicitly vote against the change you want to make either.
What do you think about this?, how can we know who doesnât vote at all and who is just not aware/interested in that single motion?
But if that person isnt aware of that motion why should we expect they are against it? If you dont explicitly say no you arent saying yes. If 5% say yes and you dont say no, youâre only 5% saying yes. Are you scared of the situation where 1% agree and 99% dont care? My argument would be that without a veto and 99% explicitly being apathetic it should pass.
Note that the moment you open your client for the first time you can turn off frequency voting. You dont need to explicity say no every time, you just explicity say that you will say no until you say yes and you are right back to where we are right now. Only those that leave defaults set to defaults will experience a defaulted vote. This is true even for motions that have not been hashed yet.
(I hope that made some semblance of sense)
4 Likes
A small fraction of vote comes with a bigger variance or statistical error. A motion passed this way has a weak consensus. It runs the risk of being nullified by another few nay-sayers coming out of the woodworks, eventually wasting time, effort, and resources than not passing it in the first place.
I think frequency voting is OK down to 30% voting rate or 25 votes (error of 25 is 1/sqr(25) = 20%)
I did simulations for this.
The graphs converge pretty nicely with low statistical variation even at 80% apathy. Even 99.99% apathy i showed converges, albeit a bit more messily than one might hope.
Im not sure i understand that. Do you mean 25 votes in a 10,000 block window? Cause thatâs only 0.25% voting.
How much statistical aberation is acceptable? If 48% of the network is on board, should a motion pass by random chance? Cause thatâs how the network works now. 90% apathy would kick this bar down to around 45%.
Sorry I made a typo I meant 25 voters with equal weight. N random variables has 1/sqrt(N) relative error in their average value. A better calculation could be made taking a weight distribution into account.
Depends on how controversy the result is I think. Usually 20% uncertainty is pretty pretty safe.
I saw your simulation before but couldn;r understand it although I sort of agree with the results. The chart had no labeling and the process wasnât very clearly described.