[bisq-network/proposals] Encourage usage of Bonded Reputation by calculating a score for all offers (#138)

[chimp1984]

@wiz 
I reviewed the proposal again and have some comments and at the end of the text some serious doubts (sorry loved the idea but fear it's problematic):

- The minimum locktime of 30 days seems to be too short as confiscation require at least one cycle but can take longer if some discussion/proof finding time is needed. As there is no formal process how to deal with a situation where someone makes a confiscation request i think we should be rather conservative and use at least the min. locktime for bonded roles which is 15.840 blocks (abount 3,5 months).

- We should lay out a suggested process what kind of proof is required for confiscation. For instance we could state that a proof for a chargeback from a mediator is enough. This proof from the mediator should be as stong as possible (done with PageSigner). We still need to keep it flexible as unknown reasons might lead to confiscation request and we need to trust on the DAO stakeholders subjective judgement ability. 

- To simplify the score we could omit the locktime (using a sufficiently large locktime by default). Then we could simply show which % of the amount in offers is covered by the bond (e.g. 50% of 1.2 BTC in 3 offers are covered by a BSQ bond). Having less complexity increase UX and make interpretation easier. Instead of stars we could use then a simple scale of the lowest bond up to the highest and the users score is in that range with a rounded % number (like a progress bar). Buyers and sellers need to be treated differently as seller is at risk to bank chargeback.

- I would remove the bonded role feature. There are not that many such users and I think we should keep all as simple as possible. (agree also to @MwithM 's concerns in that regards) 

> Add an option to disable or hide offers from users who have a Bonded Reputation Score less than X.
- I would add that later once the feature is widely used as otherwise initially it would not make sense to filter away most of the offers and it could create a bit too much pressure on users to make such a bond. I think we have to be careful to not force users into that but keep it a completley optional feature which is left to the traders if it will become a valuable metric or not. It also has privacy implications which again we should not create pressure to users to use a less privacy protected way. (agree also to @MwithM 's concerns in that regards) 

- Which identity key should be used for the pre-image for the hash which will be visible in the bond? It can be either the onion address or the signature pubKey which are both in the offer. Because both if those keys carry also some privacy problems and as there is work in progress to enable renewal of the onion address we should consider to create a new key for that feature. A custom bond key will give us the future flexibility to improve privay by generating new sigKeys and using different onion addresses for offers by allowing the user to selectively map offers by revealing the bond key. Privacy and identity are hard to combine and reputation requires identity so comes with weaker privacy. So there will be a trade-of for the user to weaken privacy for exchange of reputation and based on that a potentially better trade price and security. But as privacy is a strong core value in Bisq we have to take care to not create too much pressure that users need to use bonds as otherwise nobody takes their offers.

- We should differentiate between buy and sell offers as well as Fiat and Altcoin. Only the BTC buyer (Fiat) can do a bank chargeback which represents the biggest security risk. The other less critical risk is "forward trading" where a buyer decided to not complete the trade if price has moved against his favor. This is also relevant for Altcoins. But when it comes to a violation and a confiscation request for such a "future trade" it is very difficult or impossible to proof (traders can bring up some invented reasons like bug, bank problems,....). We should consider to use that feature maybe only for the chargeback risk case which delivers usually clearly a proof once the seller provides a PageSigned bank statement showing the chargeback (or any other trader who became victim of same scammer). 
If we limit it to Fiat BUY offers we should consider the context and relation to the account signing feature. E.g. enable to unlock the trade limit earlier if the Bond covers the offer amounts - but that has to be updated with each offer change so that the trader could not get his limit lifted and do then a "long con" scam.

- An interesting side effect will be that it creates incentive to remove offers if they are not likely to get taken. E.g. you have 3 offers with different prices. Now there is no incentive to remove the 2 offers with the less attractive price but with the bond you would have a lower score with 3 offers as if you set 2 offers inactive and only keep the offer with the best chances to get taken. Once its taken you enable the next offer. So this will remove network load for offers which have anyway low chances to get taken as other better priced offers are above them.


## Potential showstoppers:

- As @MwithM pointed out there is some risks with that proposal. A trader could make an offer which is covered by the bond. Once taken he publishes the next offer, still covered by the bond but the information that one trade is pending is not visible. After he has enough pending trades that a scam is profitable he could do e.g. chargebacks for all pending trades and he risks to only lose the bond which covered only a portion of the trades. The information about the finalisation of pending trades is missing and creates that security risk.
 
This could be only mitigated if we would link the tradeStatistics into the mix, but that would decrease privacy. It could be done by adding the bond hash to the tradeStatistics extraMap and users could look up that data to see how many trades have been done in the recent past and which trade amounts. Then still there is no clear information when a trade has been completed.
In fact here we are challenged by the same basic problem for the "Off-chain Trade Protocol". How to track the bond with the pending trades in a secure but privacy protecting way? I fear there is no easy solution for that.

- There is another big issue: We only cover the maker but if the taker is the buyer the maker wants to be protected to only accept takers which are bonded. In fact the chargeback scammer back in April mostly was in the role of the taker (always the buyer obviously). Any ideas how to solve that problem? 

If we cannot solve the last 2 points I fear the whole idea renders itself less useful and potentially harmful (giving wrong impression of security).   


-- 
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/138#issuecomment-565839240
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191215/8acf5ff1/attachment.html>