I had an interesting discussion with a friend about the topic and I got my doubts if the current plan are really that good.
Here are the main points and below a new suggestion:
-
The age of the account need to be either timestamped in the block chain which would require an extra tx and cause usability drawbacks or we store it in the P2P network. Without that the user could manipulate the source code and put the account creation date back.
-
I started working on the social media 2FA and its quite a bit complicate to explain to the user all the background and instructions. I also discussed it with the Bitrated dev and even he did not understand it immediately, so I fear it will be too complicated for the average user and also create more drawbacks for usability than it provides extra security (which is rather weak anyway).
-
We don’t have information about the strategies of those stolen bank account scammers. It is not unlikely that they purchase additionally to the bank account other accounts (social media accounts) which would render the effort completely pointless. If a hacker gets access to a computer they get probably much more than the bank account.
-
Trade limits are generally a way to add more friction to the a scammer and distribute risk (less likely to trade 10 times with the scammer). So we should keep those currently low limits as it is a “cheap” protection without too much drawbacks. Average trade amounts are anyway 0.5 BTC even we had 3 BTC for altcoins before v0.5.0.
-
Combining the trade limits with the age of the account/first trade would be another good approach (more on that below).
-
Reputation for number of trades would help a bit and would provide valuable information for many traders. There is some trade off between reputation and privacy so we have to think about that carefully (see below).
-
Removing the email/id check has higher priority than adding half baked new solutions. We should take enough time to get it really right.
-
Charge back should be in most cases not be possible without agreement of the seller. The seller should reject any charge back request as it is not his fault if banks and their customers fail in basic security protections.
-
If a payment method turns out to be too easy to charge back and/or make it without asking the seller we have to consider to remove that payment method. We have good reasons why we never started to support PayPal for that reason. If ClearXchange is not better than PayPal in that regards we have to remove it.
There is a new (not fully thought out) idea how we could introduce a trade limitation based on trade age and reputation (nr. of trades of maker are visible in offer).
We could put the hash of the bank account number (e.g. IBAN at SEPA) into the offer and once a trade happens put the hash into the trade statistics data.
In the offer book we can display the number of past trades we find in the trade statistics which contain that hash. The bank account number is not exposed, only the hash!
We could add a policy using the age of the first trade. If the first trade is older than 1 or 2 months it is very unlikely that the trader used a stolen bank account. If there was no trade or the first trade is very recent we can set lower trade limits and reducing risk in that way and with those lower limits we make it less attractive for scammers to use our platform.
The accumulated trade amount could be also considered for the policy.
The maker will see the takers number of trades and the age once the taker accepts the offer. The taker is also limited by his trade history so a newbie cannot take offers with high trade amounts.
Optionally we could give the maker room for deciding the policy when creating the offer (e.g. min age of trades of taker, min nr. of trades,…).
But there is one problem with that approach:
If one knows your bank account number (other traders, bank, other people who had a bank transfer with you) they could create a hash of it and look up the trade statistics (distributed in the Bisq P2P network) and see which trades (including amount) you have done.
But luckily there is a solution to fix that:
We can combine the input for the hash with a secret nonce: hash(bank account number + nonce).
Once the taker takes the offer, after he paid the taker fee the account data get exchanged and in that step we could exchange the secret nonce as well. That way the peers could verify each others trade history but only after the trade happens and the trade fees are paid.
So we could use that but then we don’t have the number of trades in the offer book and the taker does not know about the risk exposure before actually taking the offer.
But there is a solution for that problem as well:
The maker can add the relevant data (e.g. age of first trade, nr. of trades, total amount of trades) to the offer based on his real trade history. In the offer book everyone can see then those data but they cannot verify it.
Once a taker accepts the offer and they exchange the secret nonce the taker will be able to verify if the makers claims have been correct.
They could have been changed in the meantime but the numbers can only increase which does not violate the claim made in the offer. E.g. if the maker had 10 trades when creating the offer but at take-offer-time he has 12 trades it is even better and no violation, only if it would turn out that there are only 5 trades in the trade statistics it would fail the verification done be the trading peer.
So if the maker was lying the taker will find it out when taking the offer and the take-offer attempt will fail.
Unfortunately that happens after the taker has paid his taker fee (as we want to protect against data harvesting we only exchange the data after the fee is paid). But the maker would have also a damage as his offer got removed and his offer fee is lost as well. So I don’t consider that a real problem.
I think that solution would solve 2 issues:
- Providing a flexible policy based protection based on trade age, trade amounts and number of trades.
- We get the long desired reputation data in a decentralized and privacy protecting way.
Sure there might be users who prefer that they don’t need to expose the trade history (nr. of trades,…) but as said earlier reputation and privacy are not 100% compatible and we need to give the users the choice what they prefer. User who prefer more privacy can reset the secret nonce (as well as the onion address which also leaks a certain level of privacy) and then start over again as newbie with a fresh history.
We need to keep the limitations for newbies in an acceptable range, e.g. instead of 0.5 btc it might be 0.2 btc trade limit.
What do you think about that?