ghost
commented
5 years ago 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
ripcurlx
m52go
clearwater-trust
ManfredKarrer
sqrrm
angkorfilms
MwithM
Here I offer some ideas to bolster bitcoin seller confidence through 2 techniques:
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.
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.
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.
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
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).
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.
Practical Example
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:
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.