Reputation and Bonding on Mesh

[buck54321]

Hey all, I've been attacking reputation from a few different angles, but I haven't really found the right fit yet. Since others have expressed interest in this subject, I thought I'd open it up for discussion.

@dev-warrior777 shared this paper regarding a decentralized reputation system that does a good job of laying out the challenges we face. It's worth a read.

I also want to note that traded funds are protected by the atomic swap protocol, and the worst a bad actor could do is to incur on-chain transaction fees and temporarily locked funds. I think it's important to recognize that there is little incentive to being a jerk on Mesh. Bad actors can really only grief the network. There is no coin to be gained.

Features of the reputation system that I'm certain about.

• There are two level of reputation.
  • Clients track reputation data for all other clients that they interact with. We'll just call this Reputation.
  • Tatanka Mesh nodes will aggregate Reputation data reported from clients and compile into a score. We'll call this AggregateReputation.
• The number of Reputation reports considered as part of the AggregateReputation will be limited. Maybe 100 or so most recent.
• Users with low or no AggregateReputation will require a bond in order to use Mesh.
• When trading, the amount a client is willing to match with a counterparty will be limited by the counterparty's AggregateReputation. This is analogous to the trading limits in the v0 dex protocol.

Features that I'm feeling good about.

• The range of possible Reputation that clients report to Mesh will be small. I'm thinking [-127, 127].
• The possible effects of a given single interaction on a counterparty's Reputation score will be fairly limited. For positive interactions,
  the only effect would be a +1. For negative interactions, the effect could be larger, and would of course be negative.
• Users with an AggregateReputation score above a certain critical reputation score will no longer require a bond to use Mesh. Should their score drop below that level, they would be required to bond back up though.
• Bonds will be instantly refundable after their maturation period. Once a user surpasses the critical reputation score, they can refund their bond without delay.

Features I'm considering

• More recent interactions could be weighted more heavily in the Reputation score
• There could be a couple of different interaction types, with some types more persistent than others. This is analogous to how different types of interactions have different depths in v0 dex. (See matchOutcomes, preimageOutcomes, orderOutcomes in auth.go)
• There could be a sort of recursiveness built in such that a negative interaction would have a larger effect for counterparties with higher reputation. This might mitigate the ability of a user to game the system by building their reputation up so that they can do some maliciousness, rinse, repeat, while still preventing an unfortunate occurrence like a network outage from completely decimating a counterparty's score beyond the point of no return.
• Users with high AggregateReputation could hand out a limited number of voucher bonds to onboard other users. These would act the same as regular bonds, but would require no actual funds.

[norwnd]

Hey, the general design looks pretty clean, it's probably worth to go into some details and discuss possible failure-scenarios (to either improve this reputation system further, or at least better understand the trade-offs it makes),

would be interesting to know what happens in the following scenarios:

• lets say we have client A (a good/honest actor who has good reputation with mesh network), what does it take for malicious client(s) to "get his reputation down into negative territory" (and would that be harder if more than 1 client is targeted) ? I assume only bonded clients (and/or clients above critical reputation score) will be able to affect AggregateReputation of client A, but even then - if I can spin up a bunch of malicious clients (say, 100 of them, each bonded with small amount of DCR) and start deliberately downvoting all other clients on the network denying them mesh accesses (presumably forever, or for a long time) ... if this kind of attack is super-simple to pull off there probably isn't much benefit to having reputation system in the first place (it would just trade-off one set of problems for another); I guess this can be somewhat addressed by weighing client contributions to AggregateReputation by their overall trading-participation - so it would better reflect what "most active" participants think of this particular client A, it still can be gamed though because "most active" doesn't mean "good/honest"
• related to the above ^ when client submits his Reputation contribution to mesh server(s) does he prove this contribution somehow (eg. by providing some signature he received from corresponding counterparty client) ? And how hard would it be to fake such a proof ? Is there a way to prove ALL various misbehaviors, perhaps with server's help ?
• if the nuances listed above ^ are too complex to work out & implement in reliable & robust manner, perhaps it's worth considering something like trusted reputation sources - designated (by Decred community) clients or servers who's judgement will have a higher weight, or maybe even be the only judgement we ever really need (it could be revoked by social coordination in case such trusted server operator misbehaves in obviously bad ways)
• do server(s) provide any inputs to AggregateReputation ? And wouldn't it be simpler to leave clients out of reputation system responsibilities entirely and instead let the server(s) do all the work (naively, server(s) feels like more appropriate place to track reputation since it tracks all trades & trade-outcomes in one place) ?
• another aspect you've probably considered/discussed in the past (but I'd like to ask about it since it's relevant) is - it seems the approach you've outlined above defines reputation as a sort of "uniform truth everybody contributes too", while an alternative way to treat reputation would be for each server to figure out how good/bad each of his clients are on his own using reputation-information gossiped by all other servers only as a "starting guess" (rather than a "uniform truth"); this approach feels like a natural extension of how DEX currently behaves, server can't be fooled into thinking bad of good/honest clients, but the downside is that server is slightly more vulnerable to new client(s) initially (likely not an issue if parameters are tweaked properly)

[martonp]

Looks good.

Reputation provided by users with a higher AggregateReputation could be weighted higher in the calculation of another user's AggregateReputation.

Once a user surpasses the critical reputation score, they can refund their bond without delay.

How would this work?