Replies to Slack discussions on amounts of rewards/slashings for v5

--- tags: Proposals --- ## Should it be the case that someone can only flag once they have gotten up to some allocation so that we know they have been a part of the stream long enough? - Minimum time in bounty - Not doing it ## Flat vs. variable flag-stake (and how to choose the value of each) ## Sponsor vs. burn excess tokens after slashing # Replies to Slack discussions on amounts of rewards/slashings for v5 Common sense constraints: 1. Reviewer Fees < Flag Stake * in case of false flagging, flag stake must pay for the review 2. Reviewer Fees + flagger reward < minimum stake * slashing% * in case of correct flag, slashing must pay for the review 3. Flag stake > P(False Positive) * (flagger reward + allocations benefit from kicking out a major staker) * safety multiplier * you can't actually profit from false flagging, or even close 4. Flag stake > P(False Positive) * Slashing Risk Amount * safety multiplier * it must be a lot more expensive to raise false flags until you get a false positive, than the target will lose Example values satisfying the above constraints: 1. 1 < 10 * Reviewer fees 1 USD * Flagger reward = flag stake = 10 USD 2. 1 + 9 < 10 * Slashing% = 10% * Minimum stake 100 USD * would get slashed worth 10 USD * Here flagger reward must be capped to 9 USD * also would cap flag stake 3. 10 > 5% * (10 + 20) = 1.5 * P(False positive) = 5% * Allocations benefit = 10 days * (1 USD/day * 2) = 20 USD * i.e. false positive throws out half of total stake for 10 days, so while I normally make 1 USD/day, for the next 10 days I'll make 2 USD/day * Safety multiplier = 1 * seems to work with these numbers... though I guess "safety" here means how many times less profitable we want to make abuses 4. 250 >= 5% * 5000 * Slashing risk amount = 50 000 USD * 10% = 5 000 USD * for the biggest staker * Flag stake would need to be proportional to the Big Stake * potential problem! No one can afford to flag the Big Staker * Maybe slashing should be capped, too? * slashing could be min(0.1 * *stake*, 20 * *flag stake*)? * Note no room for safety multiplier here * Maybe review can be a LOT better than 5% false positives? ## Henri's Thread * *Letting the flagger choose the size of the flag-stake is better than a fixed flag-stake, because it incentivizes quality flags: you can earn more by being more certain about your flag.* - Problem here is the possibility of adding complexity, is this something that is important for V1 or could be pushed off until V2? - If we do go forward with it, what defines the minimum and maximum? We don't want a broker to be driving a bounty into new bankruptcy for a large bet. And is there utility past a certain point, i.e. if we get rid of one bad actor but it was a massive payout to the flagger, is that worth it incentives wise? - Flaggers already have an incentive of removing freeriding brokers from the bounty, so incentivizing through financial bets might not be needed. * *Fixed fee for reviewers is better than one proportional to the flag-stake, because otherwise for flags that don’t have the maximum flag-stake, voters have incentive to vote “nokick” and hope for a bigger flag-staker to come along.* - We agree that it should be fixed fee * *If a bounty is limited to some maximum number of brokers and it is full, then voters may have incentive to vote ‘kick’ in order to free up a slot for themselves.* - For the one in the bounty already, they don't need the space to join - The ones not in the bounty who would want to join would not be likely picked to vote because of randomness, so the peer reviewers would not have an incentive to lie (there would still need to be a majority of reviewers that vote dishonestly) - There's a risk of being penalized for false flagging, so anyone starting the process would also think about the possibility of being randomly allocated voters that vote dishonestly / false - TLDR: We think this abuse case is not a very large probability because of those points and is mainly countered by most potential voters running standardized software voting honestly * *It’s difficult to guarantee the voters are chosen that are not part of the same bounty, because there might not even be enough of such brokers in the system. In an extreme case all brokers in existence are in a bounty. How to defend against this corner case, or do we just ignore it for now, as it’s somewhat unlikely to arise in the real world?* - The idea was to choose brokers that are not in that specific bounty where a broker is voted on, but this does not have to be enforced strictly. - To reduce complexity, it is in most cases still fine if a broker is also in the same bounty, as their incentives are still reasonably aligned - And again: They'd need to count on others also running altered software for voting dishonestly * *Related to the above point, if we can't rule out voters who are in the same bounty, then burning the excess slashed amount is better than using it to sponsor the bounty, because voters that are also brokers in the bounty then have less bias. (Unfortunately they will nevertheless have some bias to vote ‘kick’ in order to get a bigger slice of the pie)* - In general, burning excess slashing amounts reduces the bias / strategic decisions both for flagging and for voting - The counterpoint: Burning vs. re-sponsoring the bounty is a question of local vs. global benefits. - If we had a bounty where someone did no work but earned rewards for some time, we do want the excess to go back to that bounty to try and reverse some of the damage done. This is the local view. - The global view is that burning the excess leads to better system health for everyone and all things held equal you would benefit from all slashings system wide and maybe be indifferent because on the average you should be benefiting from the burning as much as you would benefit locally from the excess. - Caveat: regular users also benefit from the global view of it. But then again, they also might benefit on the bounty level from having stronger bounties. - Also: if all excess slashed funds are burned then voting "guilty" has a slightly increased payoff - TLDR: Returning excess funds to the bounty can increase complexity for strategic decisions, but can make up local funds lost due to freeriding. On the other hand, burning excess funds can lead to better overall system health but benefits more actors than just the brokers that were hurt by freeriding. We are open to either way but want confirmation from the streamr team given these comments that they still want burning. ## Juuso's Thread * *There was also the idea of reviewer reward being proportional to slashing;* - It can lead to an incentive to flag the big guys, and probably is best to keep fixed - To reduce any bias in voting/flagging, it is going to make the most sense to have fixed amounts no matter what the slashing or what the outcome for the peer reviewers and the flagger (unless the flagger gets slashed for being incorrect of course). We want them to just vote truthfully * *or rather slashing being some multiple of flag-stake such that reviewers would earn more from a bigger flag (or even there could be more reviewers?). This would mean no left-over tokens: all slashed tokens / flag-stake would be divided between the majority reviewers (and flagger in case of slashing)* - This is also a V1 vs. V2 question. Having the multiple of flag-stake and having that be a variable number opens up a bunch more scenarios and edge cases. Are we sure this is something that should be put into V1 given we wanted it to be a simpler version ### Henri * *After you left we realized it creates bias due to the above point, and therefore the fixed reward is possibly better? And it will still create left-over tokens in case the flag-stake is less than the maximum - Fixed definitely feels better* - We agree - fixed feels much better overall and reduces complexity. ### Eric * *Yeah one hard property: it is important for both choices "kick" and "nokick" to pay out the same reward. Otherwise an inherit bias will be introduced. Think of a 50-50 situation, where I am equally unsure. I should still remain equally inclined to vote for either option (or maybe not vote at all?).* - Agreed! * *If the flag stake is less than the slashed stake, then the question of how to distribute the excess in case of "kick" winning becomes an issue. The excess can't be rewarded to the reviewers since this would tip the voting in favor of "kick" violating the previously mentioned property. The excess could be added to the sponsorship. However, if the reviewer choosing process is allowed to include reviewers that are also part of the bounty, then such reviewers will have a slight incentive to vote for "kick" as well, because this would extend the sponsorship time of the bounty therefore ensuring their future revenues. The excess could also be burned. Again, if reviewers who are also part of the bounty are allowed to be chosen, then such reviewers may be tempted to vote "nokick" only to afterwards set up the same exact flagging themselves only with a higher flag stake, and if the voting then passes, collect a higher reward. I wonder whether such a trade-off would be worth it if there is a risk of some other in-bounty reviewer front-running them (assuming only one flag is allowed at the same time).* - Mostly covered above. Best to have fixed payments to reviewers and flagger, any excess can be put into the stream or burned.