[Draft] Frequency Voting

Development Protocol
#61

Forking or personally distributing would not be possible as this motion very much has to do with the domain ‘nubits.com’ and supplying users with defaults.

bitbucket src/vote.h

Put this stuff at the beginning:

#include < ctime >
srand ((unsigned)time(0));

Assume we read the voting probability from the UI and called it ‘threshold’. Then put this between line 278 and 279:

tester = rand() / RAND_MAX;
if ( tester >= threshold)
------>hashMotion = 0;

The arrow (-------->) represents a tab. How much of the $5,000 does this earn me?

2 Likes
#62

We don’t have a significant problem apathetic voters yet. If the nuteam is not already being paid now, I don’t see urgency to mobilize them to implement frequency voting.

Technically the motion doesn’t specify when this should be implemented so the above is not a reason not to vote for it.

About the cost, how do we estimate cost of nuteam’s work?

#63

That would break many things. But you’re right, implementing the random part is pretty easy (and Bitcoin code already provides functions to get random numbers), but it’s a tiny part of the modification. Among the things that would need to be done I see that (but I haven’t read the whole discussion so I may have missed some details):

  • update the GUI to add the new column
  • parse GUI input and handle invalid ones
  • merge this pull request to get a different structure for user votes and blockchain votes (because right now they’re the same structure so we can’t store the extra frequency information without adding it to the blockchain too): https://bitbucket.org/JordanLeePeershares/nubit/pull-requests/247/fix-vote-serialization-problem/diff
  • update the user vote structure to store this new information among each motion vote
  • update the code that generates a blockchain vote from a user vote to take the frequency into account
  • update the vote JSON parsing (used by the setvote RPC and when a vote is received from a data feed) to parse the frequency parameter (and probably still support the old format which would put 100% as frequency)
  • update the code that dumps a user vote to JSON to add the frequency (and actually we would need 2 versions of this dump because dumping a user vote will become different than dumping a blockchain vote)
  • write some automated tests (they would be written first actually)
  • update the client version
  • build and test one or more RC releases
  • build the final version
6 Likes
#64

Thanks @sigmike for providing us some specifics on what is involved. That helps with coming up with a proper estimate for the work. As @masterOfDisaster asked above, would you also be able to elaborate on why you and Jordan decided against something similar? Do you recall what the reasons were?

#65

Forking is rather costly and I don’t think somebody would be really that committed to it, but is doable. An application for not-so-apathetic voters is that some only care about a subset of all motions and would rather vote neutral for others.

Another way would be to publish datafeeds to mimic this behavior. Yet another dirty hack would be to do all this through RPC, if only to build a prototype. Cost-benefit aside, because the goal is to reduce the influence of apathetic voters and reduce centralization, there can be steps taken before we reach the final product.

#66

I think Jordan is talking about 2 different things:

We talked about using the votes in the blockchain as data feed. That was rejected mostly because of privacy issues for the data feed providers and the lag it introduces.

We also talked about making the user votes fuzzy to protect privacy of shareholders (to prevent linking different NSR addresses that vote identically). Your vote would be slightly randomized before it’s put in the block you create. The mean value would be what you voted for, and the variance would be a parameter you choose. I don’t remember we rejected that, but instead I remember we decided it was not a priority.

[Withdrawn] Reduce mint reward to reduce apathetic voting?
[Withdrawn] Reduce mint reward to reduce apathetic voting?
#67

It seems that this draft is causing some controversy. I would have to read it carefully to get a proper understanding of the problem and the solution proposed before expressing my opinion on it, I feel.

#68

Thanks @sigmike. I like a lot your writing style. No emotions, just arguments.
I would like to hear your opinion about Frequency Voting when/if you have time.

#69

I really feel very bad about this, and I wish that if shareholders ever feel ignored they should protest as loud as they can.

I ask everybody that feels it, one way or another, to be more specific and point out what has be ignored by whom.

In most discussions happening on this forum I personally consider myself a shareholder, not someone who is called to act. So if I am not reading / participating in some discussion, I am acting as a “bad” shareholder, not as a bad team member.

My focus and space is liquidity and NuBot, and when I don’t participate in those discussion, I am being a bad developer. Please tag my username if you wish I participate to somewhere specific.

This community is so full of talent that sometimes I feel safe not reading something and confident it is in good hands.

So please, when you criticise make sure you direct your concerns in the right direction : was he/she being a lazy shareholder or a non-responsive developer?

Now, if you count team members whose action directly impact the course of the technicalities of the network, then you’ll have a lot of burden on just a few people.

Personally I wouldn’t tinker with it much because in open source project I rarely have seen these high level of productivity from core developers, especially, as @Chronos once joked , with such “low rate of LOCs/chats” .

To sum it up : raise your concerns as soon as you have one and try to be as specific as possible, and remember to discern dev/shareholders role of each person.

my 2 cents

3 Likes
#70

I read the whole discussion, I couldn’t resist.

Brilliant. And convoluted at times. But definitely I am glad I spent time catching up with it, and sorry I haven’t replied earlier. I have so many comments after 68 posts that I’ll try to keep it to the essentials, and use a separator to change topic.

Please take my comments as someone completely unfamiliar with the matter who is trying to decipher it. Help me and try to be patient if I didn’t grasped something correctly.

First I want to understand the “why” of this system. By reading the discussion I can extrapolate this as your main source of reasoning (please correct me if I am wrong) :

we would be totally frozen out with a 50% apathy rate.

while with frequency voting

we could still function at 0.01% voting

but then as I keep reading I find something that puzzles my mind a bit.

in @Nagalim’s own words

To pass, a motion would still require very close to 50% support. […]
With 30% support, however, a motion really doesn’t have any chance of passing with or without frequency voting.

I think it’s just a matter of wording, right?

So what is the “50% support” in your above sentence? 50% support among non-apathetic voters?

Let me try to rephrase it in my own words : frequency voting will make a motion tend to pass if more than 50% of active voters vote for it, as opposed as 50% of active minters in the current design.

EDIT : Then how do you distinguish an active voters from a non-active voter? How do you distinguish someone who is apathetic from someone who is willingly not voting for any motion?

Careful with the “it’s not a protocol change => its a light change” argument. The degree of impact of a change isn’t just related to “protocol, non protocol” : I can think tens of examples of protocol changes that have less impact on the network that forcing an automatic behaviour of the client. Actually I would call anything that obey a written rule systematically a protocol. It’s not THE block chain protocol, but it is a part of the stack of protocols of the network.

This discussion is too complicated to understand for many readers and shareholders. If you want to elicit more replies I suggest you make the effort of making an ELI5 and renaming this motion from frequency voting to a Automated Voting, “follow the lead” , or “On apathetic voters” .

@masterOfDisaster described it nicely :

a very nice way to keep the Nu network able to make decisions even if some or many voters don’t care about voting and are fine with following the lead of voters.

Question : is this only for Motions (binary votes), right? (and how it could be adapted to the others vote) .

Because at the current state it just target motion problems. And I evaluate the risk of being stuck with passing a grant waaay bigger that being stuck with passing a motion.

You are introducing basically passive voting by default, if I understand correctly. These passive votes would go towards the most voted motions (in a given window of blocks). Is there any case of this approach in democracy? The closest thing I can think of is the “majority premium” that gives extra seats to the winning party of an election. Wouldn’t this have the same effect of make the majority stronger? Or the average stronger?

Implications are absolutely nontrivial.

I don’t know how to read some of the charts because the legend is too small for me to distinguish what each color represents. I can’t comment on that now

While this looks sound from a technical angle, its a UX disaster.

If this change is aimed towards passive voters, adding an extra field to fill for each vote, will not help. Actually it will have the opposite effect in creating confusion among active voters like myself. When I mint I want to vote for all the motion I entered, I see no point in having a probability field. (ndr: Moreover, why default it to 0? It means that by default when I enter the hash I am not voting for it…Which is a bit counterintuitive, isn’t it? )

I would just add a checkbox somewhere in the “votes” tab called “Follow the lead - Automatic vote” which will disable buttons in the “votes” tabs.

I will try not to comment on the 50 NBT (a bit offensive if taken literally), and will try to read between the lines and understand that @Nagalim simply wanted to emphasise how a small change could have a big impact.

@dysconnect said:

I can definitely vote and rally for frequency voting but I prefer to also add a few (cheap) safeguards.

I’d also will consider adding some safeguard before implementing anything similar. In the draft I didn’t see any, correct?

@dysconnect said :

As the developers won’t have enough time to tend to every potential NuBits improvement, it is time to offload development work and expand development activities within the community.

This sounds a lot like what I predicted 1 year ago on the bounty proposal thread :

However, with new functionalities added on daily basis, NuNet enables an always growing array of possibilities. It is very hard - if not impossible - for the core-team to explore new territories while focusing on the critical day-to-day activities.

4 Likes
#71

It has been my plan to address the issue of unconfigured voting by making selecting a data feed very easy. They could be presented in a drop down list during install. This type of development just hasn’t been prioritised yet.

#72

Yes

Using defaults. An active voter self-identifies. Everyone else is non-active.

That’s a typo, basically.

At first, eventually all votes (including park and fee) once everyone is comfortable with the implementation.

There is very little chance of a motion passing without a large % of active voters voting for it.

@dysconnect proposed a safeguard and I wrote it into the second phase motion. Basically, ignore motions for the first 1,000 blocks after you see them. The trick is to look at just the last 3,000 blocks and look for stretches of 1,000 blocks where the motion is not voted on.

Great! Also, having an ‘advanced’ option to check that allows you to frequency vote manually.

It was probably about half that and half not knowing at all how much these things cost. No one has proposed motions that specify prices for things except me and JL, and JL’s are always in the hundreds of thousands. I figured I’d low-ball. Sig-mike’s comment was very informative for me, excellent communication.

That’s what the end result of this proposal would be. The client would eventually be selecting data feeds for you.

We have flexibility that real-world democracies should be salivating over.

Because security comes from those who just want to go about their lives unconcerned but participate in the system and decision making comes from those who come to conclusions about the state of things and choose one way or the other. Data feeds cause centralization of voting power, frequency voting patches that fundamental flaw.

Possible Process Flow:

  1. Implement basic frequency voting as an advanced feature.
  2. Have a checkbox which auto-populates the motion box with the top 5 (or whatever) motions voted for in the last 1000 blocks.
  3. Have a checkbox beside each motion which auto-populates a voting probability (hidden if advanced mode is not turned on) based on the last 1000 blocks. Use the aforementioned safeguard.
  4. Check all boxes by default.
  5. Apply to other votes, like fee and park.
  6. Allow subscription to a linear combination of data feeds and default voting.
  7. Correlate data feed histories to voter history to automatically pick a linear combination of data feeds and default voting.

The flow will change with time, of course. By step 4 we will have achieved something truly monumental.
As far as I understand, JL is proposing $5,000 just for step 1. Step 1 is all Sigmike was spelling out, for sure. If we assume $50/hour (a senior developer salary) that would mean that it takes two and a half weeks of full time developer work to do the work described by sigmike. Is that accurate?

2 Likes
Auto-Populate Client Motions
#73

+1

#74

This post is relevant to this discussion:

1 Like
#75

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
#76

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?

#77

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
#78

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
#79

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
#80

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).