Skip to content
This repository has been archived by the owner on Jun 17, 2020. It is now read-only.

slashing conditions in the RAM budgeting and Reward system? #261

Closed
dckc opened this issue Jan 30, 2018 · 45 comments
Closed

slashing conditions in the RAM budgeting and Reward system? #261

dckc opened this issue Jan 30, 2018 · 45 comments
Assignees
Labels
bounty-contract changes to the bounty system operating agreement; see CONTRIBUTING.md Development splitting into core-dev, developer-education, ...? (guides: @dckc, ...) zz-Operations NEEDS SPONSOR guides: @TrenchFloat, @jimscarver @Tonyprisca13

Comments

@dckc
Copy link
Contributor

dckc commented Jan 30, 2018

This distributed budgeting and reward system is a distributed consensus process. We're now learning that it is not robust in the face of bad actors. Considerable effort is spent correcting unwelcome interactions: Jan 29 in #115, Jan 30 in 246

In Casper there are "slashing conditions" where a validator loses, financially, when it mis-behaves.

What negative consequences can / should we add to our process to make it more robust?

@dckc dckc added the zz-Operations NEEDS SPONSOR guides: @TrenchFloat, @jimscarver @Tonyprisca13 label Jan 30, 2018
@dckc
Copy link
Contributor Author

dckc commented Jan 30, 2018

@zsluedem has left several "drive-by" comments that I consider counter-productive. For example: #259 (comment)

The github reaction tools should be used instead. I'm inclined to add this to CONTRIBUTING.md.

@dckc
Copy link
Contributor Author

dckc commented Jan 30, 2018

I believe github has a mechanism to ban users from a repository. I don't know whether anyone other than @lapin7 has access to the repository settings to use it, and I don't want to route all complaints thru him. But perhaps the ban feature is available via an API and we could put together some automation... if 5 people vote to have someone banned, they are banned temporarily... for 3 days at first, with the duration increasing for repeat offenses. They could appeal their case via other channels such as [email protected].

p.s. Remove user as a collaborator is supported in the github REST API:

DELETE /repos/:owner/:repo/collaborators/:username

@lapin7
Copy link
Contributor

lapin7 commented Jan 30, 2018

I'm happy with the feedback on the system.

There are admin settings that can remove a collaborator from the repository. So we need more admins.
[email protected] is mainly used for managing access rights to RChain/Members google drive. It's not meant for communication. Communication happens in Discord, Telegram or Mattermost.

I'm not a fan of board's that decide for us. If there are bad-actors, simply give them -10000 % so that their reward becomes 0 RHOC. And give your motivation in the comments of the issue.

We have to improve our Issues, Defining them SMART.

On February, 1 the Budget 201801 and Rewards 201801 will be frozen and analyzed/cleaned by @lapin7. The result will be a more or less fair distribution of RHOC compared to the efforts. And we go on with Budget 201802 and Rewards 201802.

Remember that this is an evolving experiment, one of the first of its kind. Each month it becomes better. Below you find a history of this little flower.

Historic overview:

So anyone can raise an issue, if s/he thinks it's good for RChain. The limitation is to find 2 others to back your idea up. At least 3 people are necessary to set the budget. If you're alone then no budget is allocated and thus no rewards being given. At least 3 participants on the issue have to express their view on the reward for each person. If you don't get 2 other participants backing your view up, then you don't get a reward.

Anyway this system is evolving and of course there will be more rules and restrictions in the future, but the progress is amazing to me:

  • From Jan to July 2017 there was nothing. Only a few collaborators, no system.
  • In August a free to spend budget of 100.000 RHOC was approved
  • Then we got a few collaborators
  • Then we decided to use Github as a management tool
  • Then we started bridging our channels (@drbloom, @jimscarver, @kitblake, @entropee , ...)
  • We made a reward system with spreadsheets (@jimscarver, @lapin7)
  • We made an onboarding system through google forms, but it got overruled by others
  • We still have a lousy onboarding system, with lots of manual tasks
  • The issues got into a spreadsheet by screendump, copy/paste/clean and the folks were manually added
  • From August to November Budgets were set by @lapin7 and rewards as well, because nobody took the pain to go for the RHOC's. It was based on participation with comments in github issues
  • December I stopped filling out budgets/rewards and the folks got angry by not being paid
  • Now the issues and the collaborators get filled by a script (thanks to @dckc)
  • The folks enter for the first time in January the budgets and the rewards
  • Results of work done has been of little concern
  • Issues are still poorly formulated and not SMART, the github features are not much used
  • In December there has abuse of the system and the problem of trust became a problem
  • In January the folks start to correct each other by entering negative rewards see M> Community Co-operators #115
  • In February Results and Rewards will get more attention
  • A long the way, things get better and the productivity is IMMENSE. look e.g. at M> Translate video Exclusive chat Lawrence Lerner & Nash Foster  #251 M> Translate video Exclusive chat Lawrence Lerner & Nash Foster

@dckc
Copy link
Contributor Author

dckc commented Jan 30, 2018

If there are bad-actors, simply give them -10000 % so that their reward becomes 0 RHOC. And give your motivation in the comments of the issue.

But that puts a burden on me to find all the bad actors. And giving a -1000% vote still gets them closer to 3 votes. "Bad money drives out good" is a mnemonic for the phenomenon where bad actors ruin whole systems if given the chance. If it's easier to tear down than to build up, then the whole system comes down. And we know that building up, i.e. real contribution, is not easy.

Plus, the confrontations are uncomfortable. I'm confident we can do better.

@zsluedem
Copy link
Contributor

Oh, I was doing it trying to catch up the progress.
But you are right about it. Sorry for the burden~
this shows the concrete permisions we can make to the user~!

@AbnerZheng
Copy link
Contributor

Yeah. I think those who did really and solid contribution should have the right for voting percentage of work. And for budget, I think the voter must know how it is going and what is the meaning of this thing, so that I think the relevant people should firstly be invited to make the budget voting as @dckc did in #185, because they know the value of the issue, maybe in this way, the number of bad actors could be reduced.

@Viraculous
Copy link

The question is , what are the parameters of identifying solid contributions? @AbnerZheng sometimes solid contributions maybe passive and unrecognized. I personally think that all newbees should be on boarded in a nursery group where they are educated on ethical values of the cooperative and also the criteriology of liquid democracy on budgeting and participation. They should be made aware of the implications of being unethical in budgeting and rewards. This is because a lot of more bad actors are yet to come.

@AbnerZheng
Copy link
Contributor

@Viraculous Yeah, I'm agree with you. We're are all learning how to how to process these things. I believe we can do better.

@pmoorman
Copy link

RE: commenting isn't the same as contributing

Agreed with both @AbnerZheng and @dckc that the value that is attributed to commenting is excessive.

I spoke about it with both @dckc @Mervyn853 and @traviagio before, and my conclusion is that a simple change in attitude could do a lot of good.

Our guiding principle should be:

Comments are worthless unless they comprise delivered work

I'm borrowing this quote from @dckc in private chat, but I think it captures perfectly how many people feel about this.

Comments help move things forward and also help build the community, but they should be differentiated from "doing the work".

RE: "slashing conditions"

This is really the scope of this issue, but my suggestion would be that a cultural mindset-change towards structural devaluation of commenting would solve most of the immediate issues.

Maybe the 'staking' concept could be a valuable concept to explore in the future, but for now I think it adds too much complexity.

Education & onboarding

Growth of the member base brings some 'growing pains', but it also points us towards directions were solutions might be.

Here is a quote from what BelovedAquila said in #246 (and subsequently received a lot of flak for):

this is a cooperative platform. And a cooperative is of the believe that no matter how little ones participation might seemly be, it still counts to certain percentage of total contribution done. Every participate counts, a participation being little doesn't void it from being a participation.

(emphasis mine)

I disagree with BelovedAquila, but that doesn't mean that "he is wrong". This is a about the values/beliefs of our cooperative setup, and should be something we can decide on as a consensus of members. (there might already be a set of values articulated in the past?)

Once we have agreement on what the value we operate by, we should push hard on education & onboarding new members, to make sure everyone understand our (shared) coop values.

@pmoorman
Copy link

pmoorman commented Jan 31, 2018

RE: negative rewards

I'll take the situation with Mervyn853 and Keaycee in issue #115 as an example.

This is my view:

The way negative rewards work contradict a “distributed consensus process”.

Although I agree with @Mervyn853 's decision in #115, if we're being honest it's really just Mervyn having veto power over everyone else's opinion. The faith of Keaycee is solely in Mervyn's hands. This approach is not in line with the decentralisation of decion-making that we are trying to achieve:

  • Mervyn’s superpowers are not democratically-controlled. Now instead of having a centralised dictatorship, we have an odd kind of decentralisation where in effect everyone can be a dictator!

  • At the very least, negative rewards should have -100% as the max value. That should be more than enough for a group consensus to adjust the situation.

  • I think negative rewards should not be given at all. It would help to have a way to vote "this person should get nothing" which actually doesn't exist right now, because 0.00% is the default value in the cell and doesn't constitute a vote.

Summary: negative voting runs counter to a decentralised democratic consensus, because one person can effectively override the consensus.

We should look for different solutions to solve the problem.

@Viraculous
Copy link

Viraculous commented Jan 31, 2018

I have had background in Cooperative Economics and Management and by that come to know that the problem is more of inefficiency in human resource management and which would not be possible except through education/enlightenment on esteemed value/ethical structure of the organization especially in a decentralized platform as the RChain where there is no central authority or a well defined governance structure. Bad actions or SMARTless participation can be majorly attributed to ignorance or miss information but this problem can be curbed during member on boarding process; by providing a nursery platform where on boarded members of all strata are sufficiently informed of the essentials( factors necessary for the continuance) of the community and also, having their ambiguities cleared through Q&A before being part of the main channel of the community. To facilitate constitutionalism, the newbees should be made aware of the sanctions of ethical misconduct. The negative budgeting isn't bad for sanction but should be analysed closely on its reflection in the community cooperative model of identity. Am in concord with @dckc on 5 votes for temporal sanction.

@lapin7
Copy link
Contributor

lapin7 commented Jan 31, 2018

I will freeze the 201801: Budgets and Rewards as it is at 2018-02-01. The last update was today. Up to #270.

And start the payment process and a new month 201802. All closed issues won't appear in 201802. Closed issues can be reopened but don't get any budget or reward anymore. If you want to go on with a closed issue, you open a new one with a reference to the closed one.

I will analyse the situation of 201801 and come up with a report of my conclusions. I'm happy with all the feedback and will implement those in 201802 that seem OK to me. There will be some unfair payments, but we have to take that as a learning price.

I will try to delegate some tasks of the maintenance and evolvement of the system to some RAM's (RChain Active Members) in order to speed up the workings of the whole budget/reward/payment process.

The goal is to get a decentralized smooth and fair system, while on the go. Mind you, I'm not going to "repair" errors. Errors can only be arranged by making effective and fair changes in 201802 onwards. This way of working is so, because it's too time consuming to undo once made decisions.

BTW it would be nice to have a Gsheet-specialist to help me improving the system. @dckc has been helping me already an awful lot. :-)

@jimscarver
Copy link
Contributor

@dckc slashing conditions on bad actors are needed in the end game however I'd prefer to frame it as tough love.

I think onboarding people onto the rchain culture before enabling them in github is a good idea. I suggest if someone acts badly flagged by two members their github access can be removed until two other members attest that they are reformed.

Voting negative is a problem. I suggest voting 0% should not be counted the same as not voting. Three members vote zero that should block payment. This allows vote moree explicit objection.

@dckc
Copy link
Contributor Author

dckc commented Jan 31, 2018

@Viraculous is your point about a nursery platform pretty much the same as in #243 that you raised? It's a good point that perhaps that would reduce the burden of dealing with bad actors.

Aside from the 5 votes for temporal sanction possibility that we agree is worth consideration, do you see any particular mechanism or steps to take in the area of negative consequences?

@pmoorman
Copy link

pmoorman commented Feb 1, 2018

@jimscarver's comment captures what for me feels as the "conclusion" of this discussion. All his points seems to have a broad level of consensus/agreement (both here, and in other issues):

@dckc slashing conditions on bad actors are needed in the end game however I'd prefer to frame it as tough love.

I think onboarding people onto the rchain culture before enabling them in github is a good idea. I suggest if someone acts badly flagged by two members their github access can be removed until two other members attest that they are reformed.

Voting negative is a problem. I suggest voting 0% should not be counted the same as not voting. Three members vote zero that should block payment. This allows vote moree explicit objection.

I would consider his answer as the defacto "final answer" to this issue, unless anyone objects.

+++++++++++++

Moving forward, I think there are 2 actions we should take:

  1. @lapin7 should find a way to implement 0-voting (and seems like he could use some technical help). Multiple 0-votes should be a red flag.

  2. We should talk about values, most noticably our attitude towards the value we attribute to commenting and other forms of "secondary contributions" that don't constitute the meat of the work.
    Once we agree on our values, we should communicate them clearer to (new) members.

Suggestion: Maybe both actions should get their own respective issue?

@BelovedAquila
Copy link

BelovedAquila commented Feb 1, 2018

"people err because of lack of knowledge" and "when purpose isn't defined, abuse is inevitable". All the contributions made are really impressive and in line. But as it regards to solving it I move with @Viraculous,enlightenment before sanctions (based on a legal dictum, people don't really tend to obey rules and follow principles just because there is a sanction, some tend to obey or not because of what they feel is right or because of some ideology, notion and perception they naturally have a it partains to rules laid and principles placed ). There is a need to really clear the ambiguities that are seen mostly by newbies and even certain old collaborators as it partains to the budget system. It won't be on a fair and balanced scale of judgment if people are prosecuted for defaulting on things they clearly seem not to understand how it works, even though ignorance isn't always an excuse. My summarized point is the Bad actors might not be erring with a clear intention of erring, rather because of their ignorance of not knowing "what is what " and "what is not". But in a case where it is a clear intentional defaulting of the laid down principles as partains to the system, then sanctions should made.

Now the question are:

  1. what are the principles?
  2. who are the bad actor's? I.E how do we tend to know who did what?
  3. what would be the sanction?

My suggestive solutions to resolve this questions are:

  1. Avenue like a platform should be created where by all blurry ambiguity which each member holds (old and new) can be resolved, just like @Viraculous elaborated.
  2. trusted, fair and non discriminatory collaborators should be observed and stationed to monitor the bad actors, as a person can't carry all the burdens like @dckc complained.
  3. the reasons the budget system is manipulated is either as a result of the nudge to make gains (extra gains) or suppress gains.so the sanction bases would be more effective when the instrument used to carry out injustice, is likewise used to execute justice. I. E the use of the - % method.

To add to:does no other person but myself seem to observe that his /her usernames are either removed in the budgets or placed on issues (with a budget being placed), which wasn't his /her doing?

@lapin7
Copy link
Contributor

lapin7 commented Feb 2, 2018 via email

@dckc
Copy link
Contributor Author

dckc commented Feb 2, 2018

@pmoorman writes:

I would consider his answer as the defacto "final answer" to this issue, unless anyone objects.

It's useful to observe that a critical mass of support is building, but it's not enough that noone objects. Unless someone takes the ball to carry out the decision, we're not done.

I'm thinking through the details in issues such as #260 and #279.

@dckc
Copy link
Contributor Author

dckc commented Feb 2, 2018

@lapin7 writes:

A google doc keeps versioning of changes. Bad Actors can be found.

I couldn't navigate the history of the spreadsheet. I have no confidence in my ability to find bad actors that way.

Bad actors can behave with intent or accidentally.

Accidents are usability failures of the system, mostly; I consider that separate from bad actors, i.e. fraud.

Is some kind of export possible?

Yes; dbr_norm.py is (an export of) the jupyter notebook I'm using to migrate the 201801 data. In #260 , I asked whether you want or need me to migrate other months.

@Viraculous
Copy link

Viraculous commented Feb 2, 2018

Exactly @dckc. Suggesting some thing like "RChain Nursery" where principal values are explained and confusion cleared. Like early stated, bad act could be intent or ignorance

@dckc
Copy link
Contributor Author

dckc commented Feb 7, 2018

Remember the advogato trust metric? I'm inclined to try it here.

I wrote an interactive simulator for it back in Apr 2010. I just checked and the simulator is still working.

@traviagio and @pmoorman I especially want to look at how well it addresses the cases from your analysis.

I'm inclined to try it out with data from github such as followers and reactions.

p.s. refinement: to certify someone as master, star their fork of this repo. It's easily revoked and robustly attributed. The follower mechanism has an established scope that's broader than RAM: how do we know RAM A didn't follow RAM B for purposes unrelated to RAM? still thinking about journeyman and apprentice.

ref:

@dckc
Copy link
Contributor Author

dckc commented Apr 27, 2018 via email

@dckc
Copy link
Contributor Author

dckc commented May 10, 2018

I turned on slashing along with the trust metric (#375), provisionally, for 201805; see discussion in #616 for more.

See: slashing votes

@dckc
Copy link
Contributor Author

dckc commented May 30, 2018

@TrenchFloat, reminder: you said you'd make a screencast how-to video on slashing in the b&r app wiki page.

ref:

@dckc
Copy link
Contributor Author

dckc commented May 30, 2018

The only other pending work I'm aware of is updating CONTRIBUTING.md. Anybody else want to do it? Otherwise I guess I will.

@TrenchFloat
Copy link
Contributor

I added a "slashing" section to the bottom of How to Use the Budget Rewards Web App, complete with screencast video tutorial. Can somebody test the video to make sure it plays? I'm not sure about .webm files...

Feel free to edit the text in the wiki page too. cc @dckc

@kitblake
Copy link
Contributor

kitblake commented Jun 2, 2018

The video plays fine (tested with Firefox).
Despite being somewhat ancient (the pay period is March) the video is really helpful.

dckc added a commit that referenced this issue Jun 3, 2018
 - Limit votes to trust-certified members (#375)
 - Document slashing (#261)
@dckc
Copy link
Contributor Author

dckc commented Jun 6, 2018

The rewards app should make it easier to figure out that you've been slashed. For example, the "rewards for (you)" link on the left should have a "you have been slashed in #nnn" link.

I say should, not must, because the slashing voter is also obliged to be in communication with the party that they're slashing. Slashing should be a last resort in a negotiation.

@lapin7
Copy link
Contributor

lapin7 commented Jun 9, 2018

@dckc
Please set the current month to 6/1/2018 (and freeze the month of 5/1/2018)
The RHOC rate for May = $1.38

@dckc
Copy link
Contributor Author

dckc commented Jun 9, 2018 via email

@lapin7
Copy link
Contributor

lapin7 commented Jun 9, 2018

The conversion USD to RHOC is wrong. Should be /

USD RHOC * /
4643 6407.339978 *
4643 3364.492754 /

@dckc
Copy link
Contributor Author

dckc commented Jun 10, 2018 via email

@dckc
Copy link
Contributor Author

dckc commented Jul 4, 2018

I fixed a critical bug that was affecting @jasoncruzzy in #754:

  • e3b6dad slash_judgement: don't treat 0 as slashing vote

Thanks for bringing this to my attention, @David405 . cc @allancto

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bounty-contract changes to the bounty system operating agreement; see CONTRIBUTING.md Development splitting into core-dev, developer-education, ...? (guides: @dckc, ...) zz-Operations NEEDS SPONSOR guides: @TrenchFloat, @jimscarver @Tonyprisca13
Projects
None yet
Development

No branches or pull requests