<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=4233784" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/flix1">@flix1</a> Thanks for the interesting idea.</p>
<p>Technically it can be done by requesting the trust assignments from the peers you choose by a request message and the peer responds with their trust list. There is some privacy issue though, maybe you don't want to reveal with whom you have traded to others? Maybe it could be limited so that only trusted peers can request that data?</p>
<p>For makers rejecting peers which are not above the custom trust level might be a bit of usability issue as the taker does not know if he is inside the maker's trust tolerance. Default behaviour would be that he gets rejected with an error. But of course that can be improved so that the taker gets a more informative feedback. So that should not be a major issue...<br>
Adding additional messages in the take offer process might have some backward compatibility challenges, but are probably solveable.</p>
<p>We have to be careful to not make it too hard for newbies to find traders. It would decrease the existing liquidity. My personal experience on LBTC was that it is very hard to find traders if you are a newby and then price is usually very bad or those are low trusted as well (newbies). So entering becomes more frustrating and a certain feeling of being a "second class" user can creep in.</p>
<p>But beside all that, how much security does it add to the 2 main risks of scams (stolen account, money laundering)?</p>
<ol>
<li>
<p>A stolen bank account scammer can trade a while until it gets detected in that time he can start gaining trust. The negative trust indication is not required here as such severe scams lead anyway to a ban by the filter mechanism, so nobody can ever trade with that onion and payment account anymore. So the trust score here would be more valuable if it gets some age factor based on the first usage of the account in a real trade, otherwise it can create for short time false impression of security. From our experience it takes 1-3 weeks for chargebacks. Negative feedback might be dangerous - flagging competitor traders has some financial incentive...</p>
</li>
<li>
<p>The money launderer scammer is more difficult to handle as it might take much longer until his account gets detected by the banks and it is not known yet if chargebacks are happening in such cases (so far we see currently no chargeback happened from the suspected cases). It can even be that we never know about. That some users gets closed their bank accounts for undisclosed reasons, as it happens quite often with N26 or Revolut might be indications that they had received money from money launderers but we have no facts about that. So all our time based protection tools do not work as we likely never or very late detect such cases. Those scammers are likely very active traders who transfer fast and therefore might get quickly earn positive reputation (fast release time, good prices,...). The hidden problem that the seller might get issues later with the bank once the scammer gets detected is not visible at all with that reputation idea.</p>
</li>
</ol>
<p>So I think that idea is helpful for distinguishing fast traders from slow ones or ones who do "future trades" by canceling in case of high volatility but I fear for our current focus to protect against the above 2 types of scammers it will not add protection. We also need to take care to not create signals for a wrong feeling of security which is not covered by the type of protection. That is true for the other ideas as well. Just because we can be very sure that the user is not a chargeback scammer of money launderer does not mean he is a fast and honest Bisq trader (still could cancel out in case of high volatility, be very uncooperative in disptues,....). But I think those problems are less severe and the security deposit is already a good protection (for the "future trades" issue).</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/proposals/issues/78#issuecomment-490733862">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNSNFARHSJFFX4HM7DDPUOODHANCNFSM4HHTGH4Q">mute the thread</a>.<img src="https://github.com/notifications/beacon/AJFFTNXUBBFBDVYRTRFRWXTPUOODHA5CNFSM4HHTGH42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVAACJQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/proposals/issues/78#issuecomment-490733862",
"url": "https://github.com/bisq-network/proposals/issues/78#issuecomment-490733862",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>