[bisq-network/proposals] Negative reputation tied to payment account (#27)

[Manfred Karrer]

## 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 him selves 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!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/27
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20180607/0422806a/attachment-0001.html>