N-factor counterparty confidence mechanisms

[m52go]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Here I offer some ideas to bolster bitcoin seller confidence through 2 techniques:

• verify buyer identity though multiple methods for each trade before any money can be sent to seller
• mark/sign payment accounts which fail this verification step, and immediately blackball them from trading

The fundamental concept is to (continually) seek to prove a trader is bad, rather than seek to prove (once) that a trader is good.

In a way such a system could be less risky for the network in the long-term, because it would be built on distrust instead of trust, without reliance on a single trust chain where the network's integrity can be tainted with a single mistake. A downside here is that it makes individual traders responsible for establishing a counterparty's integrity on their own, for each trade, but as you'll see below, I think the proposed methods are relatively simple, quick, private, and (when used in combination) robust.

Because only "negative reputation" can be earned (i.e., in this concept, signed accounts are very BAD), there would be fewer ways for a scammer to "game the system." He can take extraordinary measures to pass verification for every single trade he does, but that's not an exploit...that's how this thing is supposed to work.

Objective

Prevent buyer from sending payment until seller is confident about the buyer's identity, so that if/when payment is sent, chances are high it was initiated from the rightful account owner.

Disclaimer

These ideas are meant more as a starting point for discussion and further ideas than a solid solution ready to implement.

Some of these ideas are a bit off-the-wall.

Concept

Currently, once deposit transactions are confirmed, the buyer goes right to sending payment.

But what if the buyer was forced to identify himself before he could send payment?

Identity is virtually impossible to prove online, so this proposal offers a handful of methods a buyer could use to increase confidence in the seller that he's not bluffing—it's never possible to be 100% sure, but maybe we can get to 90% or 95% certainty by combining 2 or 3 or even 4 methods at a time.

So we offer multiple identity verification methods a buyer can use to boost a seller's confidence. The buyer pre-determines which of these verification methods he's comfortable with proving when he creates his payment account, and upon entering a trade, the seller can challenge the buyer to prove his identity using any of those methods the buyer previously selected.

The more methods a buyer employs & verifies for an account, the more confident a seller can be in trading with him.

Payment details should be hidden from the buyer until the seller indicates he is confident about the buyer's identity. I'll discuss other technical considerations below...I'm hoping they aren't too significant.

Identity Verification Methods

These are merely the methods I've come up with so far. I hope there are more...please share if you have other ideas, and also please voice any concerns about the viability of each one.

Keep in mind that no single method is good enough to stand on its own, so we seek to establish high confidence by combining a number of methods that (together) would make it highly unlikely that the buyer is a scammer.

Putting the burden of proof on the buyer every time he makes a trade with a new peer magnifies the value of account age—in the off chance a scammer is able to do all the tedious, hacky work necessary to successfully thwart 2 or 3 identity verification methods once, he would have to ensure all aspects of his false identity remain intact again and again for every trade, for weeks, months, etc...and the minute he fails just 1 check, his payment account is toast.

On the other hand, there's virtually no reason for an honest trader to ever fail an identity check, and most checks below are quite simple and quick.

As you review the suggested methods below, keep in mind that not every user will want to employ every method below, and not every method makes sense for every payment type either.

Each of these methods would probably require a peer-to-peer chat mechanism be built in to Bisq.

1. Buyer sends seller small payment from second bank account

Seller matches full name on payment from second bank account with full name on primary bank account

PayPal is what I initially thought to use, but upon closer inspection, PayPal probably won't work, as a scammer could simply sign up for PayPal using the exact same primary bank account—and PayPal doesn't seem to show the receiver which payment method was used for the transaction. PayPal is pretty terrible for most things anyway so I'm glad we have a good reason to avoid it.

Sending money through a service like MoneyGram could also work, because they would require ID. But it's probably a hassle to do this for most people since it would require going somewhere in-person.

• Verifies: full name
• Usage: all payment methods where full name is required
• Integrity: derived from KYC procedures of the secondary bank
• Ease: probably high, as a transfer can be done online, quickly, with little effort
• Downside: scammer with stolen identity can make another bank account to thwart this measure
• Privacy: good, as no new personal details are uncovered aside from secondary bank account details

2. Sign string using PGP key posted on public websites, OR simply announce your next post to your Bisq peer before making it

Buyer includes public key in Bisq account details, seller verifies buyer's fingerprint exists on public websites (ideally more than one of the following: buyer's blog, twitter, github, keybase, etc), and seller challenges buyer to sign string (e.g., trade id) with corresponding private key

Alternative: in talking with Manuel, it became clear that PGP is more for convenience (or inconvenience, depending on your perspective). A buyer who wants to avoid PGP could simply include links to their online profiles in their Bisq payment account, and announce updates to those profiles in a peer-to-peer chat with the seller. The seller can then verify that the buyer made the updates as he announced them, so he must have control of the accounts he claims.

While this method would require a small education effort for users, it can act as a multi-factor verification method on its own. Combining with another method would make it even stronger.

• Verifies: full name (assuming websites with fingerprint include user's full name)
• Usage: all payment methods where full name is required
• Integrity: derived from difficulty of a hacker infiltrating all a user's sites and posting a fingerprint for a public key that's older than the Bisq payment account, and/or the difficulty of establishing a whole new (convincing) web presence for a person from scratch
• Ease: high, once Bisq buyer generates GPG keypair and posts it on his site/social profiles
• Downside: users would need to know/learn basic GPG functions, but all commands are simple enough for a short doc/video
• Privacy: good, as no non-public information is disclosed, and posting fingerprints is something many people do already and is not a conspicuous activity

3. Post trade id on website with matching WHOIS data

Buyer posts trade id on website with domain name where whois details match those of Bisq payment account, and whois details haven't been updated during the life of the Bisq payment account

This might sound a bit contrived for your average user, but I think it could also be addressed with a short tutorial on configuring a custom domain with a simple static site, which is easier than ever now if you use the right tools.

• Verifies: full name
• Usage: all payment methods where full name is required
• Integrity: derived from difficulty of a hacker infiltrating a user's legitimate website, OR changing whois details for a site he owns before creating the payment account in Bisq
• Ease: high, just upload a text file to server containing the trade id
• Downside: only applies to people who own domain names without privacy, as well as hosting they control
• Privacy: good, as no non-public information is disclosed

4. Snail-mail random key to street address

Seller snail-mails buyer a random string to the address listed in his Bisq payment account details; if buyer can confirm receipt, street address is verified

• Verifies: street address
• Usage: bank wires, and other payment methods where street address is required
• Integrity: derived from practical difficulty of overcoming geographic distances and intercepting snail mail
• Ease: medium, as one has to use snail-mail
• Downside: snail-mail can take a day or two, and it doesn't apply to most payment methods (Bisq doesn't work with wires at the moment)
• Privacy: good, as sender doesn't need to put return address on envelope

5. Verify phone number through Signal

Buyer sends seller trade id via Signal, and seller matches Signal phone number with phone number in Bisq account details

While Zelle is built on phone numbers, it can be used without the mobile app, so verifying that a buyer has current control of the Zelle phone number can be useful (but not fool-proof).

• Verifies: phone number
• Usage: only with payment methods like Zelle which require a phone number
• Integrity: derived from difficulty of hijacking a phone number (which is relatively low, it seems)
• Ease: easy
• Downside: given the relative ease of hijacking a phone number, this method may not be as robust as the others, but given the low effort for users, it might be a nice third factor for payment methods based on phone number
• Privacy: good, as Signal doesn't retain metadata

6. Verify photo id data with app like ProofMode (buyer sends seller signed picture of their face, which seller can verify was taken within the past few minutes, has adequate likeness, and was taken at the location on the actual id)

Basic idea here is that the user includes a photo id (driver's license, debit card, etc) with sensitive/unnecessary information blurred out (driver's license number, debit card number, etc should NOT be shown), leaving only information that's revealed in the payment method (full name, maybe address, etc)...and then sends a signed picture of their face at the time of the trade that includes their location.

This method would be easy for a scammer to exploit, in theory, as they could simply photoshop the original picture id with information they can control, but keep in mind that if a scammer decides to photoshop an id with their own face, they'd have to show their own face at each attestation, which is highly unlikely. A more likely attack vector is for the scammer to hire a rightful account owner to do this for them, but again -- such a practice would be impractical for a scammer to do consistently, and easy for an honest user to do consistently.

As with the other methods listed here, this method would need to be used in conjunction with another method above for it to have any notable strength.

• Verifies: face, address
• Integrity: derived from difficulty of spoofing GPS and/or facial appearance (or from the spammer's willingness to show their own face)
• Ease: easy
• Downside: user has to show their face, but this could be a very good thing if it bears likeness to photos on personal website, social media, etc to use in conjunction with method 2 from above
• Privacy: with adequate blurring, photo id shouldn't show any additional information (beyond picture of face) that's not already revealed in the payment account.

Practical Example

• buyer creates sepa payment account
  • in payment account details, there are additional fields for each identity verification mechanism: secondary bank account details, pgp key, website, etc.
  • buyer fills in data for verification methods he likes
• buyer accepts offer to buy bitcoin
• after bitcoin deposit transactions are confirmed, payment account details only show to the seller
  • seller asks buyer over p2p chat to prove identity through methods listed on the buyer's payment account details
    • if successful, seller acknowledges he's comfortable with his payment details being shown to buyer, and deal carries on as normal
    • if failure, seller opens dispute and works with arbitrator to determine if buyer is a scammer. if scammer, account is signed.

Signed accounts are effectively blackballed from trading immediately (see "Quarantining signed accounts" below).

In case of a scammer, seller payment details are never revealed to buyer, so no money is ever sent to the seller, greatly reducing the chance honest traders end up dealing with shady/stolen property. This is huge for sellers...if banks start to think you're a shady person (which can very well happen if you receive money from just 1 shady account), you might run into major life-long disadvantages in opening new accounts, obtaining credit, etc.

Technical Considerations

Aside from the peer-to-peer chat tool, I'm hoping these additional measures aren't a huge pain to implement.

Peer-to-peer chat

It would be important for trading peers to have some way to privately communicate with each other to verify the buyer's identity. This is already on the roadmap as a part of the new trade protocol, and the methods proposed above assume this mechanism is in place.

Quarantining signed accounts

If it's not technically possible to outright block signed payment accounts without resorting to an emergency filter message, then we can use the UI to strongly discourage trades with signed accounts from happening:

1. offers made with signed payment accounts should be clearly marked in the offers view so traders know not to take such offers
2. offer makers should immediately open a dispute if a trader with a signed payment account takes their offer

Trade protocol

I don't think we would need another step in the trade process to make this possible, but there would need to be a way for the seller's payment details to be hidden from the buyer until the seller acknowledges their comfort with the buyer.

Trade periods might need an extra day or two to allow time for buyers to prove their identity.

Concerns

Scammer could keep making new accounts after failure to verify identity. But he'd keep hitting the same wall, as he'd never be able to verify his identity, so it would be irrational to keep wasting time trying. And he'd be starting over with 0 account age every time, which is regarded with extra scrutiny anyway.

Verification methods may have limited accessibility at first. Many people don't maintain a web server, and many users probably don't use PGP either, but I think good documentation and videos can go a long way to solving this. Yes, users would need to do some extra work to understand and implement them. But it's 1-time setup, for the most part, and not too hard if explained the right way. And, what's the alternative? The centralized alternative is to rely on dumb legacy ineffective pieces of paper, but end up getting your identity stolen anyway...the decentralized alternative is to be a victim to scammers.

This is a new way of doing trust in a decentralized way. Users should be encouraged to do this feeling like they are part of something new and something better—because they are.

Furthermore, for the PGP method, I think the requirements for using it here are simple enough. We're merely using it for signing and verifying, not for email or anything that requires more than a couple of quick commands that users can largely copy and paste. And over time, some functionality like verifying signatures could even be built right into Bisq.

I think the secondary bank account transfer combined with the PGP method (which can be a multi-factor verification method on its own) can become highly effective and accessible for most users.

Verification methods need to be carried out for every new trading peer. Would be great if we could figure out a clever way to cache previous successful trading peers locally (beyond onion address -- by actual payment account) so verification doesn't need to be done again for 2 people who have traded before.

[ghost]

I'm also in favor of such kind of negative reputation system.
I'll add to that the simple idea to host somewhere a blacklist of hashed bad IBANs.
This is simple, costs ~nothing, doesn't hurt privacy.

In the long run, maybe we should have a thinking about the benefits/drawbacks of facilitating fiat daytrading on Bisq. imo this is a real honeypot for scammers, and, volens/nolens it's forcing us to build a gas factory.
Generally, entity grow by reinforcement. ie improving what works well and not insisting on what works poorly. It's a kind of natural law. Ignoring that in the long run puts the whole project in danger imo.
I'm scared by the braintime we all use for issues that concern so few volume, while at the same time we neglect systematically other possible growth path.
If the growth path Bisq neglects decides one day for one reason or another to neglect Bisq, Bisq will find itself naked, relying only on fiat trading which is the path which proves to scale badly atm, and will probably scale even badlier in the future.
I understand we'll probably use 2 more months to try to secure fiat trading. 2 more months where we'll do ~0 for altcoin trading on Bisq. I find that really dangerous.
Altcoin trading is what pushes Bisq in the direction of profitability (which in turn is good for all trading on Bisq). Fiat trading is pulling Bisq in the opposite direction. Altcoin trading supports fiat trading. The reverse is not true. Monopolizing Bisq's few ressources on fiat is very dangerous imo.

Everybody, look at the numbers and the trends for EUR, USD trading on Bisq. The trend is quite old and well-established. This trend is simply far too small to lead to sustainability.

[mpolavieja]

no money is ever sent to the seller, greatly reducing the chance honest traders end up dealing with shady/stolen property

This is very interesting. For me the delay was a very important measure to protect private property by restoring the damages to the fiat victim and by avoiding damage to the seller. This is even better as it prevents that from happening!!, which as you say is very good for the seller not to have problems with his bank.

Verification methods need to be carried out for every new trading peer. Would be great if we could figure out a clever way to cache previous successful trading peers locally (beyond onion address -- by actual payment account) so verification doesn't need to be done again for 2 people who have traded before.

As @flix1 stated in this comment verification should always be done at payment account level. Couldn´t it be possible to store locally a whitelist of trusted payments accounts?

[ripcurlx]

I also like this proposal as it focuses more on seller than buyer protection. The only problem we have is to have secondary verification methods that are safe and available to everyone. Also when we enable communication between the two parties we have to pre-define the verification process for each methods so no-one can easily be tricked by a scammer.

@HarryMacfinned

In the long run, maybe we should have a thinking about the benefits/drawbacks of facilitating fiat daytrading on Bisq. imo this is a real honeypot for scammers, and, volens/nolens it's forcing us to build a gas factory.
Generally, entity grow by reinforcement. ie improving what works well and not insisting on what works poorly. It's a kind of natural law. Ignoring that in the long run puts the whole project in danger imo.
I'm scared by the braintime we all use for issues that concern so few volume, while at the same time we neglect systematically other possible growth path.
If the growth path Bisq neglects decides one day for one reason or another to neglect Bisq, Bisq will find itself naked, relying only on fiat trading which is the path which proves to scale badly atm, and will probably scale even badlier in the future.
I understand we'll probably use 2 more months to try to secure fiat trading. 2 more months where we'll do ~0 for altcoin trading on Bisq. I find that really dangerous.
Altcoin trading is what pushes Bisq in the direction of profitability (which in turn is good for all trading on Bisq). Fiat trading is pulling Bisq in the opposite direction. Altcoin trading supports fiat trading. The reverse is not true. Monopolizing Bisq's few ressources on fiat is very dangerous imo.

Everybody, look at the numbers and the trends for EUR, USD trading on Bisq. The trend is quite old and well-established. This trend is simply far too small to lead to sustainability.

The problem with doubling down on one payment method in general is that we increase the risk of having nothing at all if it is gone. So we have to play a short and long game - focusing enough on XMR and other markets to keep it attractive for these users, but still be able to seize the opportunity of a risk free fiat on-ramp into BTC. This differentiates us clearly from everyone else and is the hard thing to do. So if something is hard to do, it is not only a bad thing, but also a big advantage for the ones who solve it IMO.

[m52go]

verification should always be done at payment account level

Agree. But I'm starting to think blocking could happen at the onion-address level...no need for users to put up with a scammer's other bad accounts. Maybe the UI could suggest addresses to block in real-time based on signed payment accounts, and every software release could include an updated blacklist.

Couldn´t it be possible to store locally a whitelist of trusted payments accounts?

That's exactly what I'd like to see.

[clearwater-trust]

I agree, the seller should have an opportunity to vet the buyer before providing payment information (If they wish). I don't believe creating more programmatic obstacles is a good use of time. We already have the most valuable obstacle for fiat traders, The Security Fee. We will find an economic threshold that precludes petty scammers. It's imperative that we send the correct message to our fiat traders: "Fiat traders are welcome, the success of your trade is your responsibility. Bisq cannot protect you from the deficiencies of your fiat system."

[ManfredKarrer]

@HarryMacfinned
The mission of Bisq is the Fiat on-ramp. If that would be gone it is not Bisq anymore as it was envisioned. Sure XMR is super important and there are a few important ideas on the roadmap to boost that market. 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.

@m52go
The payment account details are exchanged 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.

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.

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.

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.

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.

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 be useful as well, but as said I fear we wil not cover a broader user group by that.

I am not sure how easy it is to register a webpage with a fake ID. I fear it is relatively easy. Also would cover only a small user group.

Sending a key to an address is a very interesting idea but I fear there are security risks involved (though would not add any new risk 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 an 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 about Bitcoin to the bank.

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.

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.

[ManfredKarrer]

To summarize our current knowledge and protection tools:

There are 2 types of scams we are focussing:

1. Stolen bank accounts
2. 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)

Protections tools:

• Security deposit
• Trade limits based on account age
• Account age witness
• Ban by filter
• Payout delay
• New signed account age witness with decentralized tree of signatures (Distributed reputation system #78)
• 2FA - payment with another bank account
• Proof ID with governmental certificate
• BSQ bond
• Requesting an ATM or bank branch withdrawal (Certification for ownership of a bank account #23)
• P2P chat
• Off-chain trade protocol base on BSQ bonds (Off chain trade protocol using BSQ bonds #32)

Security deposit

Currently in place. Adds risk for scammer if fraud gets detected his deposit is gone.

Trade limits based on account age

Currently in place. Adds risk and friction for scammer but is not sufficient as we learned.

Account age witness

Currently in place. Does not help if scammer is willing to wait and leave the stolen account untouched until the account age is mature.

Filter based ban

Currently in place. Bans scammer by onion or any payment account data. Effective and fast but helps only after we detected fraud.

Payout delay

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.
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 ;-(.

Decentralized reputation

Helps against stolen account scammers if fraud was detected in < 1 month. Does not help for ML case.

2FA

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).

Governmental certificate

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.

BSQ bond

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.
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.
There is also some BSQ volatility risk.

Requesting an ATM or bank branch withdrawal (#23)

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.
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.

P2P chat

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...

Off-chain trade protocol base on BSQ bonds (#32)

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.
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.
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.

Conclusion

I think against the stolen bank account scam we have some strong options. A possible strategy could be that:

1. 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.
2. If he provides a governmental certificate the limit is removed (still normal trade limits)
3. 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?).

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.

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.
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!

[mpolavieja]

2FA
Does not help against ML with fake ID

I don´t want to sound naive, but I think 2FA could help at least a little bit against ML faked IDs. It exposes the scammer a little bit more, and it forces him to do a little bit more of work such us finding 2 banks instead of just one that don´t ask too many questions and evidence about funds' origin (the latter makes it also a bit harder for bought IDs).

Taking @m52go idea of easiness for the honest user vs. scammer, a good key metric to assess the effectiveness of each protection tool is how easy it is for the honest user to overcome the protection challenge with respect on how easy/risky/difficult it is for the scammer (in this case it looks to me very easy for the honest user and at least uncomfortable for the scammer).

[sqrrm]

I quite like the idea of 2FA of different varieties. The key would be to focus on those that give the best user experience and would actually be used.

The second bank account seems quite strong but if it has to be done for every trade I suspect it would be too annoying. It would only have to be done once for each new peer though so perhaps it's reasonable.

Something that could be automated within Bisq would be a lot easier and more attractive. Even though it might be somewhat complicated for a new user to set up a fingerprint it might then be possible to verify everything else automatically going forward. These sites are not as reliable as a second bank account though.

I don't like the idea of sending physical mail, but if the mail address is already available there is no real harm, I just don't think it would be a popular method and probably better not to spend our time on.

Phone numbers could probably be an ok method, just limited to some payment methods and also not that secure.

Regarding the bonding, I think it's too early to start relying on BSQ for bonds as a security for trading. While it's a really nice idea, we're not there yet. The DAO needs some cycles to show it works and the I also think the bonds would be a big hurdle for new users, it's not an easy sell to ask new users to buy in with a fair chunk of money and locking that up for a good amount of time.

Over all I think it's a good idea to add some 2FA options and tie them in with our other measures. The measures discussed don't decrease the privacy of users much but they do decrease privacy somewhat. Having options for 2FA would let the users choose what they find the least invasive.

[m52go]

Using PGP is a good idea but I fear it will only be done by a smaller group of our traders.

I realize this idea is ambitious, but I think we need to take stock of where we are. Users use Bisq to trade Bitcoin, itself built on public/private keys. And this is Bisq, where users are more cognizant of these fundamental concepts -- that's often why they use Bisq in the first place.

Recently I spoke with a Bisq trader who is a pharmacist...not a guy you'd expect to use PGP for email, but he had just set it up after figuring it out on his own.

And let's not forget the Bisq DAO might be one of the most complicated things ever introduced to a consumer, and many Bisq users took the time and effort to understand it (proof: they're using it).

If there were ever a user base to implement such an idea, this is it. Integrating basic functions into the UI would be great. Maybe we "do things that don't scale" at first...e.g., have calls to help new users ask questions and get set up. Not sure -- we can figure it out. Ultimately it's a communications challenge, one that I see as WAY less ambitious than the challenge we faced for the Bisq DAO.

---

These sites are not as reliable as a second bank account though.

Agreed. Combined with a second bank account would be pretty great, though, I think, and may even be a deterrent for ML. I can't imagine many of these people have access to good online profiles. I know tools to generate fake online profiles exist (ICO pumping techniques were nasty), but the results I've seen wouldn't convince most people.

---

And as Manfred outlined above, this is just 1 technique we can employ.

But speaking as a hypothetical user, I can tell you it's my personal preference...by far. Having to wait 30 days to make a real trade is a major buzzkill, maybe even fatal, and the chances I'll lock up a big bond in a token I don't understand or care about are slim to none. I also don't have access to any kind of governmental certificate for this purpose either.

Without such mechanisms, there's a good chance I would be very excited to get the software and then never end up using it.

Good verification methods can establish a high-enough degree of confidence to allow people to start trading immediately (at the moment, second bank account + PGP seem like a good combination).

No one has to use it, but having the option there is vital for new users, I think.

[ManfredKarrer]

Re PGP:
If we integrate it we need to handle the key storage as well. Some users might not feel comfortable to allow key storage in another app. Integrating it with OS key management might be more difficult/complicate on the dev side.
The PGP key alone has no value (costs) regarding security against scammer, so we need to make sure the way how the key is connected to any reputation (webpage, WoT,...) is well understood by the user and does not lead to false feeling of security. I fear that is the main problem. If I would not have my key on the Bisq release page I would not have much I could demonstrate. A few people signed my key but using WoT is another challenge. Who would take the work and follow up the signers reputation to make a meaningful decision that I am trustworthy?
Don't get me wrong I am a big fan of PGP but also I see how little it is still used/understood after so many years, and as said it need to be connected to a strong reputation source.

Reputation market (just brainstorming)

Maybe we need to see all those options as a marketplace where anyone can deal with which it's most appropriate to them. How to decide how valuable one option is will be difficult specially once it gets more complex (Pgp -> webpage where its posted). If every user has to do that for himself it becomes expensive from UX and also dangerous as scammers will manage to trick people. Best would be if all those options get converted to a number (price) which reflects its value regarding security. The price finding is though an unsolved challenge. If it would be a normal good it would be a market place where others bid for it. But who wants to bid for a reputation of someone else? Maybe a betting system could do it. I bet with 1000 BSQ that user A who provided a PGP key and a webpage where it is posted is not a scammer. If he is a scammer I lose my BSQ. But those bets would need to stay open very long time and who will bet against beside the scammer who would bet for his own bet and make money that way ;-). So that will not work...

Another approach would be to lend BSQ to others for a BSQ bond. So if you are a new user and do not want to set up a bond yourself as you don't trust the system you could find one who is willing to do that for you and you pay an interest rate for the time of the bond. The one who is giving you the bond would make a rating with you where he checks out if you are trustworthy or not. So the work for evaluating the secruity would be delegated to those persons and the trading peer don't need to deal with that but he has the high security of a BSQ bond. I think that could work but not sure if there is a demand for that (similar as the idea for a general lending market for BTC). I fear people don't want to pay any interest rate and the person doing that becomes a bottleneck for privacy concerns in case there are not many of them but just a few.

[m52go]

I've added another possible verification method above.

6. Verify photo id data with app like ProofMode (buyer sends seller signed picture of their face, which seller can verify was taken within the past few minutes, has adequate likeness, and was taken at the location on the actual id)

Basic idea here is that the user includes a photo id (driver's license, debit card, etc) with sensitive/unnecessary information blurred out (driver's license number, debit card number, etc should NOT be shown), leaving only information that's revealed in the payment method (full name, maybe address, etc)...and then sends a signed picture of their face using ProofMode at the time of the trade that includes their location.

This method would be easy for a scammer to exploit, in theory, as they could simply photoshop the original picture id with information they can control, but keep in mind that if a scammer decides to photoshop an id with their own face, they'd have to show their own face at each attestation, which is highly unlikely. A more likely attack vector is for the scammer to hire a rightful account owner to do this for them, but again -- such a practice would be impractical for a scammer to do consistently, and easy for an honest user to do consistently.

As with the other methods listed here, this method would need to be used in conjunction with another method above for it to have any notable strength.

• Verifies: face, address
• Integrity: derived from difficulty of spoofing GPS and/or facial appearance (or from the spammer's willingness to show their own face, or from the scammer making the effort to get the rightful account owner to show their face for every trade)
• Ease: easy
• Downside: user has to show their face, but this could be a very good thing if it bears likeness to photos on personal website, social media, etc to use in conjunction with method 2 from above
• Privacy: with adequate blurring, photo id shouldn't show any additional information (beyond picture of face) that's not already revealed in the payment account.

[m52go]

PGP was considered a hurdle, but it's not absolutely necessary.

I've added a bit to point 2 above to outline an alternative process without PGP that should be accessible to virtually anybody.

I'm keeping this thread updated in case we choose to go in a more peer-to-peer route for protection mechanisms. Also most methods in this thread don't involve activity with banks, which could be an advantage.

Alternative: in talking with Manuel, it became clear that PGP is more for convenience (or inconvenience, depending on your perspective) -- not absolutely necessary. A buyer who wants to avoid PGP could achieve the same result by simply including links to their online profiles in their Bisq payment account, announcing updates to those profiles in a peer-to-peer chat with the seller (i.e., new tweet, gist, etc), and then making those updates. The seller can then verify that the buyer made the updates as he announced them, so he must have control of the profiles he claims.

[angkorfilms]

This "Trust System" is very important for Bisq to succeed and attract more users. I'm not a programmer, just a regular user debating whether to start using Bisq or keep using e.g. LocalBitcoins.

In my perception, it's (very) hard for me to use Bisq as there is no way for me to see whether I could potentially trust a user I intend to trade with for the very first time.

So, it seems risky to choose anyone without first confirming whether other users have had issues (not only scams) with that user before or not: e.g. bad attitude, long wait times, etc.

To be honest, I feel that once this issue of "Trust" is addressed, a LOT MORE people will feel confident to use Bisq. It's marketing fundamentals.

[mpolavieja]

@angkorfilms as my experience I can tell you that 99,9% of Bisq users are honest and all trades settled rather quickly. The current account age is quite a good trust indication parameter. There is a more specific implementation proposal about counterparty verification here #93, please feel free to join the discussion.

[m52go]

Could we use PageSigner to implement n-factor verification more easily?

Concretely: have users log in to various websites that include their identity (banks, credit cards, insurance companies, PayPal, tax services, etc). Doesn't matter if the service can be used to make a payment or not as long as it displays their full name somewhere.

Use PageSigner to sign that page and obtain 2+ such proofs.

These proofs could be provided to a signed trading peer through trader chat to become eligible for signing without needing to make 2 separate payments.

Upsides:

• no multi-week delay to wait for chargebacks
• no payment needed. Lots of users are not happy about needing to make a payment from a second bank account...understandably, because using just a single bank account with Bisq can create issues
• since no payment is needed, any site can be used, including payment services with high chargeback risk and sites that don't even process payments (e.g., car insurance company, tax service)

Downsides:

• PageSigner doesn't seem to work very well right now on many sites, so it would probably need to be improved for this idea to work

cc @mpolavieja #93

[m52go]

Someone on the forum recently mentioned Veruv as an alternative to PageSigner. Source is here. If it can be audited to be trusted, and perhaps forked for long-term reliability, the downside mentioned above may be solved.

[mpolavieja]

I missed the message above, sorry. For me I tried to use pagesigner once and I was unable to make it work. I´ll take a look at veruv

[MwithM]

was:stalled