Rewards voting system (“Elders system”), *dogfood version*

[allancto]

Description, including links to work already done
The “Elders” voting system is the outgrowth of a “cooperation at scale” discussion of how to make our current voting system more accessible, transparent, fair, and resistant to attack. It is a proposed method of voting rewards to contributors to completed projects for bounty rewards. In this proposed voting model, each member of our Cooperative may vote on rewards, but votes are counted with different weights. New members begin with voting weight of 1, more experienced members (“elders”) vote with higher weights and have an extended period in which to vote. If successful in practice it may be used as a replacement for our existing system, “Trustmetric”. The design of the Elders system is meant to address concerns with the current system and in particular allow all members of our Cooperative to vote, while keeping the Trustmetric feature of allowing experienced or trusted members the ability to partially or totally override the votes of less experienced members.

How it works. Let R be a number > 1, for system wR (in this case R=10). Members are classified into groups w1, w10, w100.. with voting weights 1, 10, 100.. For every 5-10 members in w1 there is roughly one member in w10, for every 5-10 members in w10 there is one in w100, and so on. This guarantees that higher weighted members (elders) may override votes by lower weighted members. In normal usage higher weighted members won’t need to vote at all, because voting will be done mostly by members with particular interest in the projects. Voting by members with higher weights will be necessary to resolve budgets which are of interest to many members or to resolve perceived misuse of the system. Design issue: do we need an explicit slashing capability which would reject the vote entirely, to be used in the case of fraud for instance, or is this best done “out of band” by revoking membership rights or flagging a budget to not be paid at all pending investigation?

The two parameters which control the system are R=10 (weights at each level are 10x the previous level) and S~=7.5 (approximate ratio between voters at each higher weight). The dynamics of the system (how weights for individual voters change over time) are undefined. The system will be seeded by team members acting together with @dckc and perhaps others.

The “Elders” system being developed here on an experimental basis may be upgraded in the future in several ways, including perhaps tokenizing the system of experience, reputation and trust here represented only as “weights”. It represents our “collective intelligence” because it grew out of issue #752 How "fair" is the current Trust metric system: Analyzing its effectiveness, which was followed by an extensive discussion in the RAM meeting 2018 0606 youtu.be/ao5f5--_RX0?t=198. Two main problems were identified in the current system: all members of our Cooperative should be able to vote on budgets, and how the budget is divided among team members should be done by the team itself since members not on the team are expected to judge the value to our Cooperative of the completed project, but not the individual contributions of team members.

The reason we’re calling it “dogfood” is that we will “self host”- once complete we will use first it to establish rewards for the team members on this particular issue. Please stay tuned and VOTE on our budget once the project is complete.

Benefits to the RChain Community
A voting system for rewards that is fair, transparent, attack resistant will enable us to encourage contributions and keep them aligned with the value they provide to our Cooperative.

Format
The components of the system itself are:

1. Basic voting system. Best would be to use an RSpace based database for the database along with a rholang contract interface. Current “trustmetric” system is based on xatabase (and graphql) over mysql, but these are difficult to maintain and almost impossible to security audit.

2. Security should require membership to access, and a higher level of security to seed or modify voting weights. Note that it’s our tradition that ballots are public, so name (discord name + github name if available) need to be made available through the UX.

3. UX should be a subdomain like voting.rewards.rchain.coop. Voter name and vote must be visible, along with an unlimited Comments field where members may explain their votes. Beyond that, It might be desirable to display current information about all budgets currently open to voting (for “dogfood” it will be this budget only though).

4. In addition, it will be desirable to have an analysis from the point of view of consensus theory as to what are known attack vectors. Even better would be a comparative analysis between this model, the trustmetric model, and other budget voting systems that might apply.

Time Frame and Measure of Completion
_Measure of Completion: dogfood trial, every member may vote on the reward for THIS project.
_Time frame: Ideal would be ready to “dogfood” before Jun 30 2018- the end of this voting period for w1 members. Informing members of the availability of the new system and giving them time to understand the system and become informed voters might require an addtitional week, which would put the beginning of the dogfood trial at ~June 23.

Team
Team Leads: TBD
Team Contributors: [HELP WANTED]
Primary Label and Guide: @allancto
Advisors:
Consensus theory: @traviagio
Rspace or database programming: @JoshOrndorff
UX: @AyAyRon-P
Security & id: @chrisb
Observers / testers: [HELP WANTED] @ddayan

Suggested Rewards
Basic voting system: $4000-8000 (or more), depending on quality
Security system: $2000-4000 (or more), depending on quality
Analysis: $2000-4000 (or more), depending on quality

Related issues, Demo’s and References

--
Disclaimer
All work and rewards are subject to member review and budgetary oversight. Participation is NOT a guarantee of reward. Quantification and recording of rewards to contributors follows a process which is under active development and subject to change without notice. Participation on and issue is NOT a guarantee of reward. Rewards are never guaranteed before completion and review, unless prior authorization is requested and granted.

Legal
Task Submitter shall not submit Tasks that will involve RHOC being transacted in any manner that (i) jeopardizes RHOC’s status as a software access token or other relevant and applicable description of the RHOC as an “asset”—not a security— or (2) violates, in any manner, applicable U.S. Securities laws.

[philipandri002]

@allancto even though this idea seem good and doable. I would have asked that we build on the already existing trustmetric.

I agree that there are some little challenges with the TrustMetric but it is still a beautiful and very smart platform that instead creating another we should all join hands and perfect the TrustMetric.

There is no guarantee that this Elder System won't have its own lapses which may even be far worst than what we face in the TrustMetric.

MY REASONs...

(1) there is no guarantee that it will be perfect and better than the already tested TrustMetric
(2) it will incurs another huge cost for the coop
(3) it will take over a month to get it working
(4)it will create proliferation of several app.. I.e every time we try an app and it doesn't work perfectly well instead of working it and enhancing to perfection somebody comes up with a new idea, create an issue out of it and get a reward for it.

SUGGESTION:I think we have a great app with the TrustMetric and all we have to do is workout the modalities and try to curtail it lapses and loopholes instead of creating a fresh ELDER SYSTEM.

To add I think the members if the coop needs to appreciate @dckc for putting up such a brilliant idea with the TrustMetric platform..

Let's build on that and get it perfected.@kitblake @jimscaver @lapin7

Thanks

[allancto]

Frank, thanks for your comment. Let me state right here at the beginning I agree with your statement: the coop needs to appreciate @dckc for putting up such a brilliant idea with the TrustMetric platform. The Elders system is a very similar, weighted voting system. The main differences are

1. Name: "trust metric" vs "Elders". These are quite similar, but not exactly.

2. Participation: In the Elders system every member will be able to vote.

3. Decentralization: In this system there isn't

4. Implementation: By choosing RSpace as our data repository, we believe there will be flexibility in the future to introduce additonal improvements. Having said that, we did discuss the various possibilities with @dckc and in fact, direct modification of the trustmetric code is our "backup" plan.

This list of differences addresses some of your points, the main exception being (2) it will introduce a huge cost for the Coop, and (4) it will introduce a huge proliferation of apps.

As to the huge cost, you are free to vote a budget of 0 for our work when it's complete, and to advise us of that in advance (as you are doing), and to recommend to other members that they vote a budget of 0. This is exactly how our system is designed to work.

As to the proliferation of apps, again that's exactly how our bounty system is designed to work. Contributors come up with initiatives, and our membership votes on whether those initiatives are worthy of support or not.

@philipandri002 thanks for taking the time to express these views!

Thanks,
Allan

[allancto]

@philipandri002 here's why I believe why you, and our Cooperative, should place a high value on this project. This introduction was written by @dckc and others, many of whom have been with RChain since the beginning and will certainly be considered "Elders".
https://github.com/rchain/bounties/blob/master/README.md

Some important things that new RAMs should be aware of:

• Be a self-starter :: because there is no boss, nobody is going to tell you what to do. Being a RAM is much more like being an entrepreneur than it is like being a employee.
• The greeter issues can help you find someone to show you around initially.
• Think for yourself :: RAMs work together like a swarm of insects does... but we need to avoid herd-thinking. We rely on independent thinking, and speaking up when you think we're going the wrong direction. Independent thought makes the coop stronger.
• Get things Done :: We value the guy that steps up and executes. Having opinions is easy, but doing the work is hard.
• Morals matter :: The crypto space is a wild-west landscape, where it's our own job to figure out our moral standards, and stick to them. We believe in transparency, openness, and fairness. But it’s ultimately up to our members to create and guard those values.
• Be nice to each other :: Most of our work happens online, distributed, remote. Be nice to each other, and easy to forgive. Even if you disagree, remember that we're all working towards the same goal.

[philipandri002]

@allancto! Like I earlier stated the Elders system sounds nice and doable my only concern which was expressed above.

Going through all that you have said I believe it is a great ideal too just like the Trust metric to bring in some level of decency, sincerity and decorum to the system.

Now my second concern is, how do we rate one to Bevan elder and another a beginner.

From the brief you said the elders would have more capacity or their vote carries more weight than the some others. Now how does one qualify to be an elder and why would someone's vote be more powerful than mine and can easily override my vote? Doesn't that also mean I have a boss.

And please I think if this works out it will be great I am only expressing my concern.

Thanks

[allancto]

@philipandri002 yes! another good question, who becomes weighted as an elder? In the future this process will become more dynamic and may require an evolution to a next generation voting system (which might involve tokens to signify experience, trust and so on). For our first iteration the process is quite ad-hoc but hopefully you will find it reasonable. Currently there are ~1500 members, so 5/10 to 10/10 requires 150-300 "first level" elders, which in fact corresponds to the current RAMs (~200). Then we need ~20-40 "second level" elders which is more or less the number of certified RAM's in the trust metric. Then we need ~8 "third level" elders which is just about the number of directors on our Board.

As far as Elders being the "Boss" i guess in some sense that's true, but our board members by and large are the people that created RChain in the first place and have the greatest incentive to see our bounty system succeed, so it seems reasonable to me that I turn to these individuals when I have a question I myself am not able to resolve. And it was they who created the RChain opportunity for me in the first place!

Also as far as Elders being the "Boss" it's our hypothesis that for most voting no one will care about voting most issues, they will simply notice that someone they respect is a team member or involved in some way and just allow those familiar to vote. Once in a while we will run into an issue that is too complicated or too contentious, and that will attract Elders to weigh in. But even there, if our consensus seeking system works well, the main consensus will likely be reached when an issue is posted, long before the voting even starts, and the voting will more reflect the quality of the work and perhaps some people will vote because they notice the work product is now helping them in some way (like "tipping"). Finally, just as a simple lock on a door is enough to let ordinary people know they're not supposed to enter, just having a system like this in place will discourage outlandish behavior because there's nothing to be gained and reputation to be lost.

Also Frank please don't feel shy about any of the comments you've made, they are thoughtful and articulate and you've added a lot to everyone's understanding of this project by asking and by allowing me to present these answers that are meaningful to me.

With appreciation,
Allan

[mjreitz]

Progress update?

[allancto]

Thanks @mjreitz ! I'm marking wontfix for now, no recent progress.

Thanks!