Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
N-factor counterparty confidence mechanisms #83
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.
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.
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.
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.
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.
Aside from the peer-to-peer chat tool, I'm hoping these additional measures aren't a huge pain to implement.
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:
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.
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.
I'm also in favor of such kind of negative reputation system.
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.
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.
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.
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.
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.
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.
That's exactly what I'd like to see.
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."
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.
To summarize our current knowledge and protection tools:
There are 2 types of scams we are focussing:
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.
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.
Helps against stolen account scammers if fraud was detected in < 1 month. Does not help for ML case.
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).
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.
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.
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.
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.
I think against the stolen bank account scam we have some strong options. A possible strategy could be that:
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.
referenced this issue
May 9, 2019
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).
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.
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.
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.
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.
This was referenced
May 14, 2019
referenced this issue
May 21, 2019
referenced this issue
May 22, 2019
I've added another possible verification method above.
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.