<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=34919942" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/HarryMacfinned">@HarryMacfinned</a><br>
The mission of Bisq it Fiat on ramp. If that would be gone it is not Bisq anymore. Sure XMR is super important and there are a few important ideas for the roadmap. But securing Fiat trading has higher prio yet and finding a solution to that makes Bisq stronger and can attract new traders who have not felt comfortable yet to use Bisq. But lets keep that proposal focussed on the topic and don't mix up with basic strategic discussions. Can be done elsewhere if there is demand.</p>
<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=735155" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/m52go">@m52go</a><br>
The payment account details are exchanges at the take offer process just before the deposit tx is created and are part of the contract which gets hashed into the deposit tx opreturn data. So to reveal later the sellers account is with current protocol not possibile. I also don't see that as a main problem.</p>
<p>To avoid that the scammer can even get an account which is considered "trusted" (by whateve means we come up) is for sure the main goal and then it fulfills as well that objective to not even get the fiat transfer started.</p>
<p>The filter based bans are effective and flexible. They are not decentralized but as its an emergency meassurement I think that is less critical - and they can be ignored anyway, so the centralization issue has less weight here. So we can ban a onion or any property from the payment account like name, IBAN,.... and the ban is immediate. So I think that is nothing we need a new or additional solution.</p>
<p>I fear requiring repeated verification will add a lot of inconvenience and also slow down trade, peers can be slow with answering... I think if we find a good mix of tools they should be used in a one-time process. Any severe scam leads to a ban anyway.</p>
<p>The 2 factor bank transfer idea is still very strong for protecting against stolen bank account scammers. I think that is one of the best ideas around and does not add much usability issues and most people have anyway more accounts. It does not though help against fake ID money launderers.</p>
<p>Using PGP is a good idea but I fear it will only be done by a smaller group of our traders. It can be integrated in Bisq (is even prepared) so users don't need to use the terminal and learn about PGP commands. The PGP WoT might beuseful as well, but as said I fear we wil not cover a broader user group by that.</p>
<p>I am not sure how easy it is to register a webpage with a fake ID. I fear it is relative easy. Also would cover only a small user group.</p>
<p>Sending a key to an address is a very interesting idea but I fear there are security risks involved (would not add any new if payment method requires that). Maybe we find something where we can piggyback on mechanisms which have been used by others to veriy the address. E.g. banks send atm or credit card to address. If we require a atm withdrawal we know the person has received the card either in person or on his address, both give some confidence. I think we should keep that idea in focus to integrate to our mix. Piggybacking on that what banks have already done is one of the most effective strategies IMO. We don't add inconvenience, we don't add privacy or security issues and the user does not reveal anything new to the bank.</p>
<p>Using phone number migth be useful for payment methods where it is part of the data. Not sure how bulletproof that is, as I assume that is like credit card fraud probably one of the most insecure areas.</p>
<p>Btw. there might be still a way to add delayed payout with the original timelock. I will add that to the other proposal about the delayed payout.</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-490741992">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNVE56KUGZHT4JHGFOTPUOUKLANCNFSM4HLNAEKQ">mute the thread</a>.<img src="https://github.com/notifications/beacon/AJFFTNQJUIVZUWQ54QM3XR3PUOUKLA5CNFSM4HLNAEK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVACB2A.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-490741992",
"url": "https://github.com/bisq-network/proposals/issues/83#issuecomment-490741992",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>