{"action":"created","issue":{"url":"https://api.github.com/repos/rchain/bounties/issues/771","repository_url":"https://api.github.com/repos/rchain/bounties","labels_url":"https://api.github.com/repos/rchain/bounties/issues/771/labels{/name}","comments_url":"https://api.github.com/repos/rchain/bounties/issues/771/comments","events_url":"https://api.github.com/repos/rchain/bounties/issues/771/events","html_url":"https://github.com/rchain/bounties/issues/771","id":331785395,"node_id":"MDU6SXNzdWUzMzE3ODUzOTU=","number":771,"title":"Rewards voting system (“Elders system”), *dogfood version*","user":{"login":"allancto","id":18097017,"node_id":"MDQ6VXNlcjE4MDk3MDE3","avatar_url":"https://avatars1.githubusercontent.com/u/18097017?v=4","gravatar_id":"","url":"https://api.github.com/users/allancto","html_url":"https://github.com/allancto","followers_url":"https://api.github.com/users/allancto/followers","following_url":"https://api.github.com/users/allancto/following{/other_user}","gists_url":"https://api.github.com/users/allancto/gists{/gist_id}","starred_url":"https://api.github.com/users/allancto/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/allancto/subscriptions","organizations_url":"https://api.github.com/users/allancto/orgs","repos_url":"https://api.github.com/users/allancto/repos","events_url":"https://api.github.com/users/allancto/events{/privacy}","received_events_url":"https://api.github.com/users/allancto/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-06-12T23:09:22Z","updated_at":"2018-06-14T17:29:45Z","closed_at":null,"author_association":"COLLABORATOR","body":"**Description, including links to work already done** \r\nThe “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. \r\n\r\nHow 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? \r\n\r\nThe 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.\r\n\r\nThe “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.\r\n\r\nThe 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. \r\n\r\n\r\n**Benefits to the RChain Community** \r\nA 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. \r\n \r\n \r\n**Format**\r\nThe components of the system itself are:\r\n1. 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. \r\n\r\n2. 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. \r\n\r\n3. 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). \r\n\r\n4. 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. \r\n\r\n\r\n**Time Frame and Measure of Completion**\r\n_Measure of Completion: dogfood trial, every member may vote  on the reward for THIS project.\r\n_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. \r\n\r\n\r\n**Team**\r\nTeam Leads: TBD\r\nTeam Contributors: [HELP WANTED]\r\nPrimary Label and Guide: @allancto \r\nAdvisors: \r\nConsensus theory: @traviagio \r\nRspace or database programming: @JoshOrndorff \r\nUX: @AyAyRon-P \r\nSecurity & id: @chrisb \r\nObservers / testers: [HELP WANTED] @ddayan \r\n\r\n**Suggested Rewards**\r\nBasic voting system: $4000-8000 (or more), depending on quality\r\nSecurity system: $2000-4000 (or more), depending on quality\r\nAnalysis: $2000-4000 (or more), depending on quality\r\n\r\n**Related issues, Demo’s and References**\r\n\r\n\r\n--  \\\r\n***Disclaimer*** \\\r\nAll 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.\r\n \r\n***Legal***  \\\r\n*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.*"},"comment":{"url":"https://api.github.com/repos/rchain/bounties/issues/comments/397375545","html_url":"https://github.com/rchain/bounties/issues/771#issuecomment-397375545","issue_url":"https://api.github.com/repos/rchain/bounties/issues/771","id":397375545,"node_id":"MDEyOklzc3VlQ29tbWVudDM5NzM3NTU0NQ==","user":{"login":"allancto","id":18097017,"node_id":"MDQ6VXNlcjE4MDk3MDE3","avatar_url":"https://avatars1.githubusercontent.com/u/18097017?v=4","gravatar_id":"","url":"https://api.github.com/users/allancto","html_url":"https://github.com/allancto","followers_url":"https://api.github.com/users/allancto/followers","following_url":"https://api.github.com/users/allancto/following{/other_user}","gists_url":"https://api.github.com/users/allancto/gists{/gist_id}","starred_url":"https://api.github.com/users/allancto/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/allancto/subscriptions","organizations_url":"https://api.github.com/users/allancto/orgs","repos_url":"https://api.github.com/users/allancto/repos","events_url":"https://api.github.com/users/allancto/events{/privacy}","received_events_url":"https://api.github.com/users/allancto/received_events","type":"User","site_admin":false},"created_at":"2018-06-14T17:29:44Z","updated_at":"2018-06-14T17:29:44Z","author_association":"COLLABORATOR","body":"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 \r\n\r\n1. Name: \"trust metric\" vs \"Elders\". These are quite similar, but not exactly. \r\n\r\n2. Participation: In the Elders system every member will be able to vote. \r\n\r\n3. Decentralization: In this system there isn't \r\n\r\n4. 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. \r\n\r\nThis 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. \r\n\r\nAs 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. \r\n\r\nAs 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. \r\n\r\n@philipandri002 thanks for taking the time to express these views! \r\n\r\nThanks,\r\nAllan"}}
{"actor":{"display_login":"allancto"}}