Negative reputation tied to payment account

[ManfredKarrer]

Overview

@flix1 suggested an interesting idea how we could use reputation without running into the sybil attack problem: To use negative reputation and tie it to the payment account (bank account).

A Bisq identity (onion address) can be easily changed but not a bank account.
Not using positive reputation avoids that a user could trade with himself and increasing reputation that way.
The arbitrator acts as trusted party who gives negative reputation in case of severe trade contact breaches. By default the score of a user is 0. With each severe contract breach the score decreases by a value of 1 to 10.

Motivation

We try to improve security in ways which are compatible with the privacy protection of the users.
Bad actors hurt the platform and should be kept out.
We have seen in the past 2 charge back cases we had so far that the scammer was involved in several disputes earlier. At least in the recent charge back case the scammer tried a triangular scam attempt (and failed), which would have led clearly to a negative score (a bold -10) with that new model.
Also in the first charge back scam a year ago the scammer had canceled several trades, though that was not such a clearly severe case (he reached his monthly bank transfer limit) but as it happened repeatedly it would have likely summed up to some negative score as well.
Beside detecting clear scammers it helps to detect users who are abusing the system for instance by "future trading" (canceling if the price moves against them). Such less severe and not 100% clear cases would be treated with a smaller score hit (e.g. just adding -1 to their overall score).

Details

In case of a severe trade contract breach the arbitrator can add a negative value (0-10) to the score of a user's payment account as well as to his onion address. The onion address is not a strong base, as he can easily change his onion address so we cannot count on that too much. Though it helps to potentially spread the score to other accounts of that user. The payment account is unique and usually users don't have a large variety of payment accounts.

The hash of the payment account is used as the key for that score. The score of the maker will be displayed in the offer. A taker will see that score before taking the offer. A maker can decide to only accept takers above a certain score level. The score can be displayed by a few icons with the score value (e.g. green icon with score 0, yellow icon for score 0 to -10, red icon for scores below -10).

The verification is done only in the trade process (similar as account age witness). The offer cannot be verified as the account data are not included in the offer, but if a maker would us an invalid hash in his offer (which would result in a wrong score) the trade will fail once a taker takes the offer and detects the invalid data while verifying the account data and the hash.

One problem with that scheme might be that a heavy trader who ends up in lots of disputes has a higher risk to collect negative score. Though in case the trader acts correctly there should not be any reason the arbitrator gives negative score. Only traders acting on the "edge" have higher risks here.

Arbitrator

The arbitrator gets some extra burden by not only resolving the dispute but also by judging the severity of the contract breach. But that is done already now as the arbitrator can decide how much of the security deposit goes to the other peer. Maybe we could even combine that so the payout of the security deposit reflects the score? I would though prefer to keep it separate and use the negative score only for really severe cases. But that is up for discussion...

Implementation

The score data is tied to the hash of the bank ID (e.g. IBAN + BIC) as well as to the onion address.
The data structure is a hashmap with the hash as key and a list of data items with the score, the signature and the index of arbitrators pubKey as value. Each time the arbitrator adds a negative score an entry will be added to the list. The total score is the sum of all entries in the list.
The arbitrator signs the hash + score and his signature as well the index of his public key (list of all arbitration pubKeys are hard coded in app) are attached to the data.

Data structure:

hash = RIPEMD160(SHA256(bank ID))
signature = EC sig (hash + score)
dataItem = score, signature, index of arbitrators pubKey  
Hashmap:
Key: hash
Value: list of data items

The same data structure is used for onion addresses, just that instead of the bank ID the onion address is used.

The offer contains the hash. With that each user can lookup the total score and it would get automatically updated in case there is a dispute where the maker receives negative score while having an open offer.

We cannot use a salt together with the Bank ID like we use it in the account age witness because a user with negative score could change simply his salt to reset his score. In the account age witness case the data represents a positive asset to the user so he is not interested to lose that by changing the salt. In this model the data is a negative asset.
By not using a salt a bank or anyone who knows the bank ID of the user could calculate the hash and then lookup the score hashmap for that user. If they can find an entry they would know that this user is a Bisq user who received a negative score.
We consider it less critical here because by default a user has no entry in that hashmap, only if he received a negative score. This problem also seems rather theoretical and with the reference text the bank has a much easier way to find a pattern which suggests that a client is a Bisq user.
Though if anyone has an idea how to improve that aspect, please share it!

[SilvanoMosca]

I have a couple of thoughts and comments I would like to share. In general as the pool of makers and takers are relatively small to derive any significant importance in one way or the other, I think at best (to weed out the bad players) is to perhaps define better instances for everyone to comment (for concensus purposes) between what might be considered deliberate or just simple negligence as a starting point. In this approach, this would alleviate tedious details of figuring out all possible outcomes on the onset of defining a problem.

For instance the negative point system seems a reasonable implementation, however, what would help me evaluate is what would constitute a -1 vs let say -4 points..... and would the points ever get back to 0?

Please feel free to comment on anything I say, as I am completely new to Forums.... :)

[cadayton]

It is worth a try I would think. Interesting concept. Count the sins not the deeds. I guess that I always try to find the humor in stuff. Also seems weird to say I'm a zero and being proud of it.

[cyphersphinx86]

Interesting way to get around the sybil attack problem.
Maybe we could have a incident category as supplement to the reputation score, so you can filter out incidents that are not direct fraud attempts, and make a more fair aggregated score.
Else the likelyhood of having bad reputation seems to increase the more you use the system.

[ghost]

This idea of negative (reverse) reputation system was also discussed on the forum:
https://bisq.community/t/sellers-beware-heads-up-chargebacks-from-cashapp-venmo-venmo-account-frozen/5388/22

A question for @ManfredKarrer :
ATM, if I understand well, the onion address is linked solely/purely to the computer used (and maybe also to the IP ?)
Could it be possible to force a user's first .onion address to be a definitive/immutable one ? ie is it possible to link the onion address to the user ?
or maybe, even if it is technically possible, it may be not desirable ?

[ManfredKarrer]

@cypherspace86 The idea is to only punish real misbehavior not honest mistakes.
Completely clear scams like a charge back lead anyway to a blocking of the user.

[sqrrm]

@HarryMacfinned It's not possible to tie the onion address to anything physical, it can easily be changed and the same one can also be moved between computers. I also think as you say that it's not desirable to have a reputation system like that as it becomes a way to identify users.

@ManfredKarrer I like this as I think this negative reputation system is a lot less problematic to the general privacy of the system compared to the account verification proposal. This seem to have very little drawback, the only real issue I see is a bad arbitrator giving incorrect ratings. That would be unfortunate for the user but pretty harmless for the system. It could possibly also be grounds for kicking that arbitrator out. This might not be as comprehensive as an account verification system but it seems worth implementing.

@cypherspace86 I imagine it would be only fraud attempts that should get a bad rating. Honest mistakes happen, but perhaps it would be possible to hide fraud attempts as honest mistakes and some kind of doubt could add up with a few too many 'honest mistakes'.

[ManfredKarrer]

@HarryMacfinned
The onion address gets generated by the tor private key which gets created at first app startup. If a user deletes that key it gets re-created, thus he gets a new onion address. The IP is not part of that and does not exist logically in the Tor network.
To change the onion address is a privacy feature, so to stick forever with one is not desirable, we even plan to allow in the app to renew it.

[ManfredKarrer]

@sqrrm
Re "arbitrator giving incorrect ratings": Arbitrator are bonded and a bad arbitrator could do more harm than giving a bad rating. So I don't consider that an issue. Though the additional burden to be judge here might be an issue. Lets see what the existing arbitrators say...

Please note that this feature does not come with the same protection levels as the verification proposal. A stolen bank account scammer with low fiat amounts can still cash out as he appears as a new fresh user with the default reputation.
I fear even that this proposal deliver relatively low additional protection. From my arbitration experience there have been very few cases where I would have given negative reputation. Probably less then 10.
So it will help to keep traders more honest and not abuse edge case situations like "future trading" and maybe take a bit more care to follow the protocol correctly (e.g. respond in time, check the banks monthly transfer limits before trading,...).

[ghost]

About arbitrators, Account/Arbitrator selection currently exhibits 2 arbitrators (with their associated.onion addresses).
Is that the right number ?

[sqrrm]

@ManfredKarrer Indeed, this proposal doesn't really target the same issue as the account verification. They still feel somewhat related and I guess the security gained is proportional to the increase in privacy risk.

[ManfredKarrer]

@HarryMacfinned Yes, there are 2.

[cbeams]

We only got 2 👍 reactions on this proposal, and it's not clear to me whether it should be considered approved or stalled. @ManfredKarrer, could you recap as to where you see this proposal is right now? I'd like to get it closed one way or the other and to make next steps clear if that's possible. Thanks.

[ManfredKarrer]

I see it as stalled though it got positive feedback (I assume some are not that aware to use the upvote feature). I am not very sure about the real value it will provide as real scam attempts are very rare anyway. Beside that we lack on developers to work near term on it. But I would prefer to keep it open to have it more accessible and maybe it serves for others for a new better idea.

[ManfredKarrer]

I think that idea is not further developed. I will leave it open still as it might still be interesting to read up and might lead to future continuation or extension.

[ManfredKarrer]

Interesting video to the topic:
Reputation systems based on crypt-anarchistic philosophy can only be based on the past not deal with the future.
https://youtu.be/gTtbkguROdk?t=2121
Might need to watch from start to understand full context.

[ghost]

I'll relate this thread to this fresh posting : bisq-network/bisq#1759

Maybe, one thing we could do, and which won't require targeting users, would be to target behaviours.
So we could simply list the behaviours which have already been proven to be dangerous or that we consider could be.
I assume that many scammers find a limited number of ways to proceed, and stand to those ways.
So by pointing out suspect behaviours, we may already treat a part of scams.

Of course, this may absolutely be still complementary with a negative reputation system.

PS: the video mentionned by Manfred above is worthwhile.

[ghost]

A quite simple idea.
Scams often are done via stolen fiat accounts.
So add as a public account info the sha256() of the used fiat account IBAN.
If/when we notice that a given IBAN corresponds to a badly behaving IBAN, then add the sha256() of this IBAN to a public blacklist. Could even be managed internally to Bisq.
So we have blacklisting, concerning the root of worries which is the IBAN, but without disclosing it.
(We can blacklist onions ... but this proves to be not super efficient).

(Sorry if this idea was already proposed/dismantled).

[MwithM]

Superseeded by #78