{"action":"opened","issue":{"url":"https://api.github.com/repos/DemocracyEarth/sovereign/issues/100","repository_url":"https://api.github.com/repos/DemocracyEarth/sovereign","labels_url":"https://api.github.com/repos/DemocracyEarth/sovereign/issues/100/labels{/name}","comments_url":"https://api.github.com/repos/DemocracyEarth/sovereign/issues/100/comments","events_url":"https://api.github.com/repos/DemocracyEarth/sovereign/issues/100/events","html_url":"https://github.com/DemocracyEarth/sovereign/issues/100","id":197893418,"number":100,"title":"Proposal : new votes allocation","user":{"login":"virgile-dev","id":11473995,"avatar_url":"https://avatars.githubusercontent.com/u/11473995?v=3","gravatar_id":"","url":"https://api.github.com/users/virgile-dev","html_url":"https://github.com/virgile-dev","followers_url":"https://api.github.com/users/virgile-dev/followers","following_url":"https://api.github.com/users/virgile-dev/following{/other_user}","gists_url":"https://api.github.com/users/virgile-dev/gists{/gist_id}","starred_url":"https://api.github.com/users/virgile-dev/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/virgile-dev/subscriptions","organizations_url":"https://api.github.com/users/virgile-dev/orgs","repos_url":"https://api.github.com/users/virgile-dev/repos","events_url":"https://api.github.com/users/virgile-dev/events{/privacy}","received_events_url":"https://api.github.com/users/virgile-dev/received_events","type":"User","site_admin":false},"labels":[{"id":303362547,"url":"https://api.github.com/repos/DemocracyEarth/sovereign/labels/enhancement","name":"enhancement","color":"84b6eb","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-12-28T18:06:23Z","updated_at":"2016-12-28T18:06:23Z","closed_at":null,"body":"## This proposal aims at finding a response to the question \"What do I do when I used all my votes?\"\r\n\r\nSome of the system design behind our first release of Sovereign is directly inspired by the Satoshi Nakamoto's economics of Bitcoin. One example is vote scarcity, when a collective start its collective it can parameter the number of votes allocated to each user when they signup. Votes are not tied to a particular proposal and a user can cast more than one vote on them (intensity voting).\r\n\r\nIn such condition members of the collective not only have to position themselves according to the proposal but also be smart on how they allocate their voting resources. (Game theory, cost opportunity).\r\n\r\nAs we've been experimenting in this particular environment really interesting member behaviors have emerged and the feeling we have is that this setting makes voting much more interesting and dynamic for the users as it becomes more complex (not binary).\r\n\r\nThe problem with this is that it doesn't work in the long run because people will eventually run out of votes. We've been thinking of ways to allocate new votes :\r\n\r\n- New votes are issued as new proposals are created\r\n\r\n- New votes are issued periodically (d/w/m/y)\r\n\r\nWe even starting doubting about users being able to allocate multiple votes on a single ballot. At one point we started thinking, \"why don't we fully embrace Satoshi Nakomoto's design principles of Bitcoin for our governance system\". And that's how we think we might have cracked it, here is how.\r\n\r\nBitcoin economics are very simple its basically the same as gold extraction. There is finite amount of gold on earth and to benefit from it you have to extract it form the soil mining. There are is finite amount of Bitcoin and to create Bitcoins miners have to solve complex cryptographic problems use computational power. A number of Bitcoins (plus transaction fees) (12,5 BTC currently, halves every four years) are allocated for them miners who solve the complex cryptographic problem and installs and brings consensus to the rest to the networks allowing to create a new block that is link to the rest of the chain. One particular thing that is interesting with the Bitcoin protocal is that the complexity of cryptographic problem it gives for solving to the miner is bound to the numbers of computers competing to solve it, so if less people mine Bitcoin it will give easier problems to solve to make Bitcoin mining interesting again and vice versa.\r\n\r\n## So how can we apply this to Sovereign's votes allocation system?\r\n\r\n- When a collective creates an instance a finite number of votes are available in the system, votes are thus made a scarce resource that has to be used carefully by the users.\r\n\r\n- Just like with Bitcoin new votes are created when a problem is solved, hence a decision is made, consensus is reached.\r\n\r\n- When vote get scarce more consensual proposals can be made by members of the group so decision can be made, leading to the creation of new votes (forcing the group to come together on smaller issues to later tackle more controversial ones).\r\n\r\n- The limited number of votes in the system guarantees that members abuse (overuse) this easy vote creation features.\r\n\r\n**Feedback is most welcome :)**\r\n\r\nWe started discussing this on a sovereign instance a few weeks ago : https://sovereign.opensourcepolitics.eu/vote/votes-allocations-in-the-long-run-for-sovereign-satoshi-nakamotos-way"}}
{"actor":{"display_login":"virgile-dev"}}