<p>To summarize our current knowledge and protection tools:</p>
<h2>There are 2 types of scams we are focussing:</h2>
<ol>
<li>Stolen bank accounts</li>
<li>Money launderer (ML) using fake ID, stolen ID or bought ID (poor guy opens bank account and hand over all data for a payment from scammer - so no ID theft)</li>
</ol>
<h2>Protections tools:</h2>
<ul>
<li>Security deposit</li>
<li>Trade limits based on account age</li>
<li>Account age witness</li>
<li>Ban by filter</li>
<li>Payout delay</li>
<li>New signed account age witness with decentralized tree of signatures (<a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="435922491" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/78" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/78/hovercard" href="https://github.com/bisq-network/proposals/issues/78">#78</a>)</li>
<li>2FA - payment with another bank account</li>
<li>Proof ID with governmental certificate</li>
<li>BSQ bond</li>
<li>Requesting an ATM or bank branch withdrawal (<a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="328760290" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/23" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/23/hovercard" href="https://github.com/bisq-network/proposals/issues/23">#23</a>)</li>
<li>P2P chat</li>
<li>Off-chain trade protocol base on BSQ bonds (<a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="343748086" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/32" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/32/hovercard" href="https://github.com/bisq-network/proposals/issues/32">#32</a>)</li>
</ul>
<h3>Security deposit</h3>
<p>Currently in place. Adds risk for scammer if fraud gets detected his deposit is gone.</p>
<h3>Trade limits based on account age</h3>
<p>Currently in place. Adds risk and friction for scammer but is not sufficient as we learned.</p>
<h3>Account age witness</h3>
<p>Currently in place. Does not help if scammer is willing to wait and leave the stolen account untouched until the account age is mature.</p>
<h2>Filter based ban</h2>
<p>Currently in place. Bans scammer by onion or any payment account data. Effective and fast but helps only after we detected fraud.</p>
<h2>Payout delay</h2>
<p>Dropped as UX was too problematic but just found that we could still use it with a timelock based (tx level) implementation. That would reove some of the UX challenges as users don't need to deal with an extra step. Would still need more thoughts if UX issues are not problematic anymore and if it can be deployed without a hardfork of the trade protocol.<br>
Protects against stolen accounts as those are likely detected in a few weeks. ML is likely not detected for a long time so delay would not help. But adding friction and uncertainty for scammers might be helpful to keep them out. But of course also keeps out honest newbies ;-(.</p>
<h2>Decentralized reputation</h2>
<p>Helps against stolen account scammers if fraud was detected in < 1 month. Does not help for ML case.</p>
<h2>2FA</h2>
<p>Helps against stolen accounts as it is very unlikely that the scammer has access to more than one account of the victim. Does not help against ML with fake ID but might be helpful in case of a bought ID (it is likely hard for them to approach the guy who sold his account again to open another account on same name).</p>
<h2>Governmental certificate</h2>
<p>Helps against stolen accounts and stolen ID. Is also likely effective against fake ID and bought ID as it adds extra risk and friction to scammer. It also is something out of the scammers usual business so might be helpful as they might avaid doing new things which have not been done in the past.</p>
<h2>BSQ bond</h2>
<p>Not much thought out yet. A simple solution would be to add a BSQ bond covering the trade amount for each trade and add the trade ID as hash to the bond so it can be verified. That would be relative easy to implement. The bond locktime need to be min 3 months to give the stakeholders enough time to make a decision. Benefit over payout delay is that it only affects the buyer.<br>
A more sophisticated solution would be to re-use a bond but that would probably lead to the concept as envisioned in the off-chain trade protocol. It is questionable if newbie buyers are able and willing to lock up a BSQ bond in the amount they want to buy. I doubt that many want to do that.<br>
There is also some BSQ volatility risk.</p>
<h2>Requesting an ATM or bank branch withdrawal (<a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="328760290" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/23" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/23/hovercard" href="https://github.com/bisq-network/proposals/issues/23">#23</a>)</h2>
<p>Would protect against stolen accounts as well as ML. It is very unlikely that scammer wants to go to a bank branch as well as he likely do not have the ATM card. Getting the ATM card in case of ML will require exposing an address. I assume it adds quite a lot of risk and friction for all the ML variants.<br>
A main problem with that idea is who is doing the PageSigner verification and the fact that PageSigner does not work with all bank pages. Beside that it adds quite a bit of inconvenience to the user.</p>
<h2>P2P chat</h2>
<p>By enabling users to communicate scammers can be detected by their language and communication style. Arbitrators reported their unfriendly and impatient style. 99% of Bisq users are the total opposite. But relying on that is rather weak as scammers will learn and the seller will not be interested to have longe conversations to find out more... Would also extend trade time...</p>
<h2>Off-chain trade protocol base on BSQ bonds (<a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="343748086" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/proposals/issues/32" data-hovercard-type="issue" data-hovercard-url="/bisq-network/proposals/issues/32/hovercard" href="https://github.com/bisq-network/proposals/issues/32">#32</a>)</h2>
<p>We also should keep in mind the plans for the off-chain trade protocol. It will change a lot the overall concept of Bisq and might be beneficial as protection as well. The BSQ bond will be then mandatory so the scammer will have a 3-4 months locktime with at least the trade amount. That might be one of the most efficient tools as no scammer can know to not get detected in that time and if so the bond will be suject to confiscation from stakeholders.<br>
We could make the delay for the release of the bond after a completed trade depending on the risk score of the user (new account, 2FA, certificate). So new users have a bond just covering the trade amount but they cannot use it for another trade for lets say 1 month if they do not provide additional security (2FA, certificate). So a scammer would only be able to do 3 trades in 3 months, probably enough friction and risk to keep him out. Newbies still have not so much burden if they don't want to trade more.<br>
But of course the "have no BTC" problem for new buyers is even more problematic as they need not only the BTC to pay the deposit and tx fee but the BSQ bond.</p>
<h2>Conclusion</h2>
<p>I think against the stolen bank account scam we have some strong options. A possible strategy could be that:</p>
<ol>
<li>A new buyer has to wait 30 days after his first fiat transfer before he can trader larger amounts (still in the normal trade limits). 0.01 BTC as it is now is initial limit.</li>
<li>If he provides a governmental certificate the  limit is removed (still normal trade limits)</li>
<li>If he makes a tx from 2 accounts (2FA) the limits are removed. Open questions about details (is it sufficient if authorized user signs or do he need to do it at each trade?).</li>
</ol>
<p>I think those 2 options to get an immediate upgrade should be enough for 95% of users. To add a payout delay makes all again more complicate as seller need to agree as well as his deposit will also be delayed. I think the 2FA is a more efficient tool with lower UX costs.</p>
<p>All those do not help much against the ML case. Thought the economics at ML is very different. The risks for the scammer regarding losses are much higher. Also the amount of money to be transmitted is likely much higher to be profitable for the scammer. So the existing tools with secruity deposit and trade limits are maybe already quite effective. The more transactions he need to do the higher the risk that his account gets detected or flagged by the bank.<br>
Maybe keeping trade limits low in case no additional proof have been provided (no 2FA, no certificate) might be enough? But that is still an area where another smart idea would be very welcome!</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/83#issuecomment-490763537">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNQPHNO2EGVFTJ2PHCDPUPBEBANCNFSM4HLNAEKQ">mute the thread</a>.<img src="https://github.com/notifications/beacon/AJFFTNTBVVDBJ6DTV2WXHHTPUPBEBA5CNFSM4HLNAEK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVAHKEI.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/83#issuecomment-490763537",
"url": "https://github.com/bisq-network/proposals/issues/83#issuecomment-490763537",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>