Closed ManfredKarrer closed 4 years ago
mpolavieja
commented
5 years ago the identity of the PayPal user sending the tiny payment wouldn't match the identity of the bank account owner in Bisq.
Ok, so when you receive a PayPal payment you see the name and lastname of the sender, right? If that is the case that´s good (sorry if my concern was silly, It´s been a long time since I don´t use PayPal)
m52go
commented
5 years ago No silly concerns! Yes -- you can see first and last name of sender.
There may be edge cases such as name changes (PayPal claims 2-3 days lead time to process name changes, but how is that done, and what happens in the mean time?) that could be openings for scammers. I'm researching them now to better understand.
ManfredKarrer
commented
5 years ago We can consider any secondary bank where KYC is strong enough as such a 2FA. Paypal might be the weakest. Lots of scams and I would not be surprised that its not hard to fake name with a Paypal account.
ghost
commented
5 years ago It's a long time since I opened my paypal account, but for what I remember, you do it with ... a bank account (normally yours). [Maybe it's even possible to open a paypal account without mentioning a bank account at all. In the case that the primary money source is transferring coming from other peoples paypal account(s)]. So I imagine that a guy with a stolen account without a paypal account associated can quite easily create it himself and do whatever he wants with. (I'm also verifying how the paypal account creation works).
mpolavieja
commented
5 years ago Even if PayPal is not the best way to do it @m52go core idea still stands. As @ManfredKarrer says the core idea is 2FA with another account so any other bank account from a different bank could do the work. Not always instant though, but this could be a very strong verification measure.
mpolavieja
commented
5 years ago Exactly, that's my point. That after a certain status there shouldn't be the need for more data. I think we could limit the revealing of trade data to 1 instance, the first trade.
@huey735 I was thinking about the use case of the one time user that just wants to privately buy around $500 - $4000 worth of BTC as a long term investment, and how we could facilitate UX for that kind of user (not having to wait to execute his trade). If the user does a minimum self verification (i.e. 2FA with 2 bank accounts, atm withdrawal, digital signature, etc) the system could allow him up to $2000 during the first month. Btw, I know that the delay option is being discarded at this moment, but this is the kind of user that probably wouldn´t mind a delay on the payment (we still would have the bad UX for the seller having to remember to take action once the delay is completed as I understand implementing an nlocktime for the release of BTC would not be easy at all as it would require a change on the protocol).
So I am constantly running into the limitation of not having trading information about the peer. Despite my privacy concerns, I fully agree that having this information would be a really powerful tool, specially during the first month. If we could have that information as "zero-knowledge" as possible just during the first month it could be extremely useful.
flix1
commented
5 years ago Instead of a distributed reputation... how about a "3 degrees of separation" system similar to that used by linkedin?
It would allow each user to label 10 payment accounts as "trusted"... and on the order book for each offer you would see a little (1) (2) (3) badge showing if the account used to create the offer is: (1) Directly trusted by you (2) Trusted by an account you trust (3) Trusted by an account that is trusted by an account you trust (-) Unknown to you or your trusted accounts
It would be merely informative, with no extra consequences or restrictions, but very visible.
Most importantly if you remove an account from your trusted list... it would disappear from all your contacts as a 2nd or 3rd degree trusted account.
Obviously this would only allow you to have up to 1110 1st/2nd/3rd degree trusted accounts... but on the other hand it seems easy to do, requires no personal identifying information and would be quite scalable.
What do you think?
flix1
commented
5 years ago A few more details about the above idea...
Degree of trust is for Payment Account. NOT for trader, user, onion seed or any other user or peer related info... to avoid any KYC slippery slope. This also helps avoid scammers switching payment accounts but keeping older trusted status to execute long cons or exit scams.
Information about trusted accounts is transmitted to the network in the same way that Account Age Witness is (account age should also be displayed more prominently in the order book). https://docs.bisq.network/payment-account-age-witness.html
Information is not centrally stored anywhere. Each node in the network has only local information about trusted accounts... plus the ability to receive 2nd and 3rd degree information from online trusted accounts.
It is crucial that trust can be easily and quickly revoked. No system is foolproof. But a system that can organically burn corrupted branches and build around them will grow stronger with time. Isolating scammers as fast as possible is very very important. Trust must be a scarce resource (hence the max 10 trusted accounts limit).
Since each payment account is already individually identified for account age purposes... all the information that you really need to store locally is a list of <1110 identifiers next to a (1)/(2)/(3). This might add a bit to the sync time for the network if this is updated often... but I believe the load would be very manageable.
Finally, this trust mechanism can also be used for negative trust as a warning and blacklisting mechanism similar to the one described in #27 .
mpolavieja
commented
5 years ago 1.Degree of trust is for Payment Account.
Fully agree on that, we should take that as a core principle for any trust/reputation mechanism.
To make it more difficult for scammers to build a trust branch by setting up colluding accounts, would it make sense that you could grant trust to others only after you have been granted trust from someone else? That would require a bootstrap procedure... such as the one proposed by Manfred using the arbitrators for the initial trust setup. Or maybe your proposal goes in the direction of avoiding that initial setup by relying more on revoking?
flix1
commented
5 years ago Hi @mpolavieja the idea is that each user holds and manages their own whitelist of trusted accounts and also shares that information with the network. There is no signing of any kind. You don't grant somebody else's "trust" or some "official" network trust... you only grant your own trust and let the network know about it.
So it does not matter if a fraudster creates a thousand fake accounts and uses them to "trust" each other... as long as you personally don't add one of them to your trusted list, they will never have a (1) next to them.
Sure, if one of your trusted accounts adds a fake account to their trusted list, you will see offers using that account with a (2)... degree of trust decreases exponentially with each step away from direct trust. That is why only 3 degrees are really viable.
However this way is fully organic and decentralized. It does not rely on any initial bootstrapping or authority (such as arbitrators).
The information needed to bootstrap it is already there in your Bisq trade history: accounts that you have traded with multiple times months and years ago are the best candidates for you to trust.
Even if scammers create a fully corrupted branch of the trust tree... users have an easy way to disconnect from it and isolate it. (The scammers can trade with themselves!)
From a UX point of view this should also be very intuitive to the social media generation. With one key factor: trust must be made a scarce resource and so the number of accounts you can trust must have a (low) limit. Hence my suggestion of 10.
flix1
commented
5 years ago From the point of view of a scammer, to abuse this system you would need to enter the trust circles of honest users. There is only one way to do that: perform multiple honest trades with that account over a period of time.
The moment the account is: -used for fraud -anything suspicious happens -a trade leads to a dispute ... or even it is just slow in completing a trade or gives bad information about payment (say wrong name or IBAN is used to make the payment)...
It will risk being dropped from the trusted list of the counterparty and replaced by a better partner in one of those 10 precious trust spots.
The system can be used not just to prevent fraud, but also to reward preferential trading partners who trade efficiently. Just like the Uber 5-star feedback mechanism signals good drivers.
Also see that it does not matter how many people trust you. That information is irrelevant and not shown to other traders. The only thing that matters is how close you are to direct trust with the other trader. So Sybil attacks or wash trading with yourself will not increase this score. Only convincing an honest user that you are also honest and reliable will have you added to their trustlist.
A scammer would basically have to exit scam individually every single trading partner by gaining their trust over time before scamming them. And here is where the warning system of negative trust could come in:
-Let's say that as well as a whitelist of 10 accounts you also locally manage a blacklist of 10 accounts. -Next to offers you see (1)(2)(3)(-)(-1) or (!).
Where (-1) means that this account is in your blacklist and (!) means that it is in the blacklist of an account that you trust.
flix1
commented
5 years ago Considering that at the moment there are at most 40 live offers by maybe 10-20 traders on the EUR offer book... it would be extremely easy to set up this system. By the time the web of trust has spread to include those 20 traders... it would take a very short time for the (!) warning sign to be seen by everyone on any offers made with an account that has been used to scam someone.
Of course this helps reduce risk for takers... but what can we do to protect makers?
Maybe a maker can choose the option to restrict their offers so they can only be taken by accounts which are in their (1)-(2)-(3) trust circles? or to exclude accounts with (-1) and (!) from taking their offers?
I don't know if this can be done easily... But I like the idea of any restrictions and bans being set by users, not by the system or any Bisq "authority".
mpolavieja
commented
5 years ago But I like the idea of any restrictions and bans being set by users, not by the system or any Bisq "authority".
Fully agree
ManfredKarrer
commented
5 years ago @flix1 Thanks for the interesting idea.
Technically it can be done by requesting the trust assignments from the peers you choose by a request message and the peer responds with their trust list. There is some privacy issue though, maybe you don't want to reveal with whom you have traded to others? Maybe it could be limited so that only trusted peers can request that data?
For makers rejecting peers which are not above the custom trust level might be a bit of usability issue as the taker does not know if he is inside the maker's trust tolerance. Default behaviour would be that he gets rejected with an error. But of course that can be improved so that the taker gets a more informative feedback. So that should not be a major issue... Adding additional messages in the take offer process might have some backward compatibility challenges, but are probably solveable.
We have to be careful to not make it too hard for newbies to find traders. It would decrease the existing liquidity. My personal experience on LBTC was that it is very hard to find traders if you are a newby and then price is usually very bad or those are low trusted as well (newbies). So entering becomes more frustrating and a certain feeling of being a "second class" user can creep in.
But beside all that, how much security does it add to the 2 main risks of scams (stolen account, money laundering)?
A stolen bank account scammer can trade a while until it gets detected in that time he can start gaining trust. The negative trust indication is not required here as such severe scams lead anyway to a ban by the filter mechanism, so nobody can ever trade with that onion and payment account anymore. So the trust score here would be more valuable if it gets some age factor based on the first usage of the account in a real trade, otherwise it can create for short time false impression of security. From our experience it takes 1-3 weeks for chargebacks. Negative feedback might be dangerous - flagging competitor traders has some financial incentive...
The money launderer scammer is more difficult to handle as it might take much longer until his account gets detected by the banks and it is not known yet if chargebacks are happening in such cases (so far we see currently no chargeback happened from the suspected cases). It can even be that we never know about. That some users gets closed their bank accounts for undisclosed reasons, as it happens quite often with N26 or Revolut might be indications that they had received money from money launderers but we have no facts about that. So all our time based protection tools do not work as we likely never or very late detect such cases. Those scammers are likely very active traders who transfer fast and therefore might get quickly earn positive reputation (fast release time, good prices,...). The hidden problem that the seller might get issues later with the bank once the scammer gets detected is not visible at all with that reputation idea.
So I think that idea is helpful for distinguishing fast traders from slow ones or ones who do "future trades" by canceling in case of high volatility but I fear for our current focus to protect against the above 2 types of scammers it will not add protection. We also need to take care to not create signals for a wrong feeling of security which is not covered by the type of protection. That is true for the other ideas as well. Just because we can be very sure that the user is not a chargeback scammer of money launderer does not mean he is a fast and honest Bisq trader (still could cancel out in case of high volatility, be very uncooperative in disptues,....). But I think those problems are less severe and the security deposit is already a good protection (for the "future trades" issue).
flix1
commented
5 years ago But beside all that, how much security does it add to the 2 main risks of scams (stolen account, money laundering)?
It does not help at all to prevent money laundering as these accounts can last for many months or even years before being detected. (Arguably all activity on Bisq could be considered an AML-risk).
It would help with stolen accounts. 2-3 weeks is probably not long enough to gain much trust and because they would need to do honest trades to gain that trust it would increase risk of detection.
...but this is maybe already covered by the amount limitations that come with account age witness... and a simpler solution is preferable to a complicated one if the benefits are the same.
flix1
commented
5 years ago Much simpler:
Display prominently in the offer book:
Information for both is already available. No major changes or innovations are needed to implement this. There are no additional privacy concerns.
This would allow takers to actively discriminate by only trading small amounts with unknown accounts and doing larger trades with those accounts that they personally have a longer history with or have been around for a long time.
We already show the number of times that you have traded with a certain trader (based on the onion address?) but not with a particular payment account.
reipichu
commented
5 years ago I have been formulating a proposal for an alternative solution to this problem, but it still needs some issues ironing out, so I will post my preliminary thoughts here:
The proposals we currently have for distributed trust and reputation systems (such as the one described above) are quite complex, which could make analysis of possible attacks quite difficult in practice. I'm also not convinced that we should move towards a system where we rely on the arbitrators as the root of trust - even though they could do this job, if we want to move to new trade protocols that remove the need for arbitration then this proposal would be a step in the opposite direction.
Our primary issue with account aging currently is that it is only a reliable indicator of stolen account risk if we can guarantee that the aging started along with the first payment made from the account. The main problem here is that a scammer can make a fake trade to start aging, and so this is what my proposal here addresses, using the much simpler idea of BSQ bonds, which have been mentioned elsewhere but I have not seen a concrete proposal as to how they could be used.
The properties of the described system are as follows:
Using BSQ bonds as the root of trust for attesting account age leads to a similar system to that described above, but much simpler and with a clear economic disincentive to attempting to cheat the system, and an easier way for us to control that economic equation, by modifying the BSQ bond required or modifying trade limits, as necessary.
mpolavieja
commented
5 years ago Hi @reipichu, I think that most of us in the community think that BSQ bonding will be the best solution. The problem is that if requiring to own some BTC in order to onboard Bisq is a barrier of entry, requiring BSQ would raise the barrier of entry even more.
Furthermore, BSQ token still needs to mature, and we need a solution in the meantime.
Proposal #93 is a more concrete approach to strengthen account age as a trust parameter. In that proposal it wouldn't be that easy for a scammer to fake a fiat payment. The real root of trust in this proposal and also in #93 is not really arbitrators but old users.
In #93 it is also suggested to put the first stones to pave the way for an arbitration-less protocol by enabling direct communication between users. And once arbitrators are gone, a decentralized blacklisting system can be implemented (we already have a rather solid conceptual design), which will be needed anyway regardless of the protocol (BSQ bonding included).
I think we should focus on the priorities set at #91. What you propose is indeed excellent input for priority number 3, but we all need to make a decision first about priorities 1 and 2.
reipichu
commented
5 years ago The problem is that if requiring to own some BTC in order to onboard Bisq is a barrier of entry, requiring BSQ would raise the barrier of entry even more.
In respect to the above, the system I outlined above would only require BSQ bonds for old users or regular traders, not for new users. The Bonded Traders would be used to ascertain whether an initial fiat payment has occurred from a new user who has traded with them - the new user just needs to pick a Bonded Trader to trade with for their initial trade.
One incentive for old users to bond BSQ to be trusted to validate new users would be that they would be able to set slightly higher margins on their trade pricing as they would have a captive market of new users wishing to verify their payment accounts by trading with them. If that incentive is not sufficient, we could also consider a stipend/interest paid to Bonded Traders each cycle - not dissimilar to the role arbitrators currently serve.
mpolavieja
commented
5 years ago Yeah. Bonding BSQ opens a new ocean of possibilities. Indeed it could be implemented that for small quantities only the sellers would bond BSQ, as you said, and buyers would not need BSQ nor BTC, just fiat, and the seller would release the BTC upon receiving the fiat. So the on-boarding UX of newbies would be much better and it could lead to dramatically increase the number of Bisq users.
But we would need to address carefully the risk of a scammer becoming a bonded seller to fake witness-sign an army of stolen accounts and deploy an attack after 30 days. If the bond is low, it could be profitable for the scammer. If the bond is high it could be impractical for honest sellers. I still think that relying on old users (> 6 months) as a root of trust is very interesting. Maybe a combination of age and bonding would do the trick.... Discussion is needed
So as I said, we need first a practical solution within the current trade protocol, and then we can start the discussions and implementation of the new trade protocol (priority number 3 at #91)
mpolavieja
commented
4 years ago Closed as approved. Although not exactly as initially proposed, account signing has been finally implemented in version 1.2.
In a discussion with @mpolavieja we developed a feasible solution for a distributed reputation system based on the account age witness but including a proof of a bank transfer. It is bases on an existing trusted element (arbitration) and from there we can build up a hierarchy of trusted traders.
The arbitrators could sign with their key all account age witness data from fiat traders who had completed the trades (fiat was trnasferred) and which have been older then 2 months. The P2P network payload data will contain the signature, the account age witness data (hash) and the public key of the arbitrator and it is distributed to all nodes. Anyone can verify the signature with the public key of the arbitrator. This will create the root of trust where the arbitrators are a semi-centralized trust root and they give those traders trust level 1.
We apply that to both buyers and sellers. It is guaranteed that the buyer did not has made a chargeback in that time frame. The seller does not give that guarantee but it is very unlikely that the scammer used his own account to receive the Fiat so it seems reasonable to include sellers and gain 50% more of initial level 1 peers.
For signing we might need to use the hard coded EC key as only that is persistant. The normal signature key would not be available anymore once an arbitrator has revoked as it is only part of the arbitrators P2P payload data. We need to think here about the future changes with integration of check for validity of an arbitrator depending on acceptance and locked up bond in the DAO. The current hard coded pubKeys will become obsolete then.
If a new user with a fresh account is trading with one of those traders who have received a signature from the arbitrators the trusted user will sign the untrusted one's account age witness data. By that he will gain trust level 2 but it will require some aging until it is considered trustworthy (e.g. the peer could still make a chargeback in the upcoming weeks). We could use a linear function to derive some trust score from that age.
It is an open question if a single signature is enough here or if we should require up to 3 signatures from 3 different trusted traders. Collusion risk between a potential scammer with a trusted peer is probably a very low risk. If we require too many it leads to some privacy loss for the trusted peer as with his public key anyone can see how often he has traded. If the number of such signing interactions are rather low the visible nr. of trades is much lower than the real number of trades and the problem is less severe.
Another open question is if the signing only would apply to buyers or both to buyers and sellers? Again if the seller is the scammer he would receive the funds on a stolen account which is unlikely that he want to do. If the victim sees incoming money he might get alerted as well and the account can get closed. So we prefer that the process of building up trust happens faster by doing it both ways rather that to be too restrictive.
All that signing and data publishing would happen without user interaction in the background.
A bigger challenge than the implementation of that part is the user experience aspect. We need to find a way to communicate those complex concepts in a simple way to users: The untrusted user need to understand why he has a low trust score and what he can do to increase that. The trade peer need to understand what risk he is willing to take (by trading with low trusted peers) and what are the usability consequences (delayed payout).
It has to be combined with the other proposal about the delayed payout. We need to support both the current account age witness system and that enhanced one with the signature of a trusted peer who has trades with you. With the current weaker account age reputation we are not protected against a scammer who is willing to wait for 1 months without using the stolen account. With the enhanced system one's account age would only start aging once you have done a trade with a trusted peer. New users would prefer to trade with a trusted peer so that they can get faster a good trust score. All that need to be packed into the UI in a way to not confuse users and to not add too much requirement for reading and understanding all that background. Probably the biggest challenge in that proposal....