New requirement for payment accounts with charge back risk


#60

It is posisible enter cash into an account, through an ATM, for instance:

It is only necessary to know the account number, no identification is required.


#61

Does that work with any ATm in Spain or only certain banks/atms? Do you know if that is available in other countries as well?


#62

It works with almost all banks, and all the most important. No card required. I have no experience in the rest of Europe, maybe someone knows, I guess it works too.

It is important that the ATM allows the direct entry of banknotes, as this allows the bank to update the account immediately. Updating the account from a cash entry in an envelope is slower and this can cause scams if the seller trusts and does not wait for a day.


#63

Thanks for the info. I would love to find someone who specializes on those payment methods (specially HalCash seems interesting as well) so we can collect enough info and understand completely the implications and risks. I personally don’t have time for that. So we need to postpone that until we have the proper resources.


#64

In Australia, the bigger banks allow you to deposit cash to another account from the same institution via their ATM.
Some need a card, some just a mobile number, others totally anonymous.
I would just classify it as a normal “cash/branch deposit” payment method though? not sure.
Not idea about other countries.


#65

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:

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

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

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

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

  5. Combining the trade limits with the age of the account/first trade would be another good approach (more on that below).

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

  7. Removing the email/id check has higher priority than adding half baked new solutions. We should take enough time to get it really right.

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

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


#66

It could work. In untrustworthy environments reputation is very important. They say the Silk Road website used the merchant’s reputation, and in a criminal environment the system worked well.

I think there is nothing against e-mail removal. It can be a source of social engineering scams.

The problem is people coming to Bisq to perform an occasional operation. They would have no reputation. This problem together with the fee of the operation, would be a barrier to entry. In an exchange with not too much volume, it is a problem. You need to do more customers every day.

The verification of 2FA by social network may not be perfect, and an account could have been stolen by a hacker, but I think security would be acceptable in the SEPA environment. Remember that in 2018 all bank transfers will be 2FA. A hacker must steal the access keys to the bank, the access keys to the social network account and the mobile and its unlock key. Is possible, yes, but…


#67

Yes I agree it must not create too high burdens for newbies. Also will not get implemented soon, so there is more time to think about it and maybe we find better solutions. Maybe the social media 2FA can be still there optionally.


#68

It would be a higher barrier to newbies if they felt that this is a scammers’ heaven. I think bisq never intented to be extremely easy to use so this is not a big problem.

That’s what I thought in first place. Then, bisq needs to create a reliable reputation system that protects privacy (yes, I know it’s not easy).


#69

Yes. The reputation system is the way, but it is reasonable to establish a security gradation according to security payment systems.

In Europe, where we can both use SEPA, a 2FA system can be established using a social network. In addition, from 2018 all banks must implement 2FA on transfers, as many now do. All this would be a redundant and fairly reasonable security system, which would allow newbies to approach Bisq and trade securely.

Another possibility is to use an official digital certificate. Here it is very easy and quick to get it, and totally reliable. I do not know in other continents. It is possible to apply online and then you should go to a government office - if you do not have a digital card - to verify your identity. There is no more reliable system than that.
Transactions could be signed with that certificate.


#70

Great work Manfred!

Here my thoughts:

To 1.
the account age should be durable verifyable even after future release of bisq version which could be incompatible with previous version (“bisq hard fork” like upgrade to v0.5.0). So, if one re-enters the very same SEPA account information, the age should be automatically detected from the blockchain/P2P network. Otherwise, people would not like to upgrade to a new bisq version when they would lose there account age/reputation

To 2. and 3.
Full ACK. I am glad that even before You had social media 2FA only optional, and account age only was sufficient. I do not have social media accounts with my real name and I would not like to link my pseudonymous bisq forum account with my real name and sepa account information.

To 4. and 5.
Here some ideas from me:

  • I think, since a new unknown SEPA account is a risk, the account holder needs to pay with time to get trust in his account. I would suggest a clear and easy rule: SEPA account can only be used for paying / buy offer creation after 30 days have passed the account creation. I do not think this is too hard. This is about trust and an longer term investment, people need just to get explained that. In the best case, this 30 days waiting period is onyl once needed (see my comment to 1. at the top). People normally have their SEPA accounts for many years unchanged, so one-time waiting 30 days can be requested for the long-term benefit of the system, if well explained.
  • The now one month minimum account has now “orange” reputation and the first SEPA buy trade is limited to a fixed value of 50,00 EUR (e.g. taking a Bicoin sell order can only be taken for the amount of 50 EUR). This is a relatively small value which everybode should be able to pay, but big enough for people to get heads up if fraudulent payment from their SEPA account.
  • Makers of “Sell for EUR” orders can state if they accept 50-EUR-SEPA buys from “orange” accounts.
  • The first initial 50-EUR-SEPA trade will be automatically closed as successful and bitcoin transferred to buyer after a fixed time of 30 days after seller has stated “SEPA payment received”. The seller can make a dispute if he suffers a SEPA chargeback in the first 30 days. The buyer gets his Bitcoin only after 30 days waiting time of trade.
  • The first intial 50-EUR-SEPA trade blocks any other SEPA buy trades. So there can only be exactly one inital 50-EUR-SEPA trade.
  • After the first intial 50-EUR-SEPA trade was closed successfully (30 days after seller has stated “SEPA payment received” and there was no dispute) the SEPA account gets reputation “yellow”
  • After one other SEPA buy was all ok and 30 days passed after that, the SEPA account status becomes “green”

To 7.
Full ACK


#71

Yes I fully agree and apologize that I did not take enough priority on that. I simply did not expect that the current P2P reputation feature is that valuable for people and it would have delayed the release even longer. But be sure that once there is another “hard fork” (should not happen more then max. once a year) we take car of that.


#72

I fear your suggestion will be a too hard hurdle for many users.
And I think to make it too cumbersome, slow, limited for scammers will be hopefully enough to keep them out. Similar to PageSigner which we can use in dispute process to verify the transfer, it is a tool to keep scammers out as they know they have no chance to succeed.

The exact metrics and implementation details are still not decided and we will make it transparent so you can add your input and feedback. But I guess we have a good starting point already. I will be too busy with other things so I need to find a dedicated developer who will lead that feature. I expect it will be implemented in the next 2 months.


#73

Hi All.

A suggestion to improve the security of banking transactions

Each user profile would have a private email. In addition, a hash would be made with the bank account number that would be published with the operation and with the offer.

When the user’s APP detects an offer or transaction with their account hash, the app send an email to the email address, warning of the transaction or offer.

This system will not protect bank accounts that do not belong to the Bisq users, only those of the Bisq users (then, that everyone becomes Bisq user!). It would also be safer to have the active APP as long as possible and create the email account on a mobile device.

The implementation of this improvement does not seem complicated.


#74

Putting the plain hash into the offer would violate privacy as anyone who knows the bank account (bank,…) could make the hash and find out who is the offer maker.
I doubt that the victim of the stolen bank account would be a Bisq user. I think most of those victims are technically not very skilled and Bisq and Bitcoin users typically are. But if we get the mainstream we might reach that group one day ;-).


#75

Well, not necessarily. In an IBAN code could be eliminated the two digits of country, the two digits of control, and another more any and even so the false positives would be very rare (In those rare cases you can open a ticket and the problem would be solved quickly)

If someone knows the account number and wants to verify if it corresponds to the hash of a transaction, the information obtained would only be clues, never evidence, since that hash could potentially belong to many other accounts

I made this proposal because some exchanges like Poloniex inform you by email of each operation and this is reassuring, because you know that if your account is used you would know it. It is what I intended with this proposal, although I agree that its usefulness would be limited, but I think it would give a good feeling.

In any case, I believe that the only completely secure way that could allow many means of payment would be to include the signature of the transaction document with an official digital certificate. Is it so difficult to obtain this certificate in other parts of the world?


#76

Ah good point with the SEPA format (not aware of the details). I think it still can work with the additional secret as your app knows it and therefore can match the trade.
Yes I understand now better your motivation (Poloniex example).
Will consider it once we work on that!


#77

Suppose I identify myself with a private key by signing the matching public key. I can then also sign a statement saying that I vouch for the owner of a different public key with an amount of some currency (BTC, for Bisq). The statement means that if an obligation (in default) signed by the other owner is presented to me, I will pay it.

Of course that opens me to the risk of the other owner’s key being compromised, but my statement can be more complicated to address this. If we establish a good protocol for the structure of the statements, they will become machine readable. The current implementation of Bisq puts the single arbitrator (Manfred, most of the time) in control of everything (when trading partners disagree), but it doesn’t provide any vouching - only a kind of escrow.

If we build out the vouching, then knowing someone in the network would give newbies some recourse in the case of cheating.

A simple example:

<identification owner="1XYZabc123..." type="ID" timestamp="2017-07-30T03:17:00Z" ...>Signature1</identification>
<voucher guarantor="1XYZabc123..." for="1Friend1..." max="1" currency="BTC">Signature2</voucher>

Signature1 is the signature produced by signing the opening identification tag (with attributes) using the public key represented by the owner attribute. The “…” in there is for attributes providing other data that the signer wishes to prove, such as real-name, physical-address, telephone-number, etc. The signer could then take a picture of themselves holding a copy of the signature, like I did with my phone number at http://imgur.com/T1RFboi

Signature2 is the signature produced by signing the opening voucher tag (with attributes) using the public key represented by the guarantor attribute.

A voucher could be tiered so that for higher amounts, the potential victim may be required to verify that the friend’s key has not been compromised:

<voucher>
    <guarantee guarantor="1XYZabc123..." for="1Friend1..." currency="BTC">
        <max amount="1"/>
        <max amount="5" verifier="1Friend2..."/>
        <max amount="10" verifier="1Friend3..."/>
    </guarantee>
    Signature
</voucher>

This XML represents that the owner of 1XYZabc123… will send up to 1 BTC to anyone (“Victim”) who can produce a (timestamped) “Promise” message signed by 1Friend1… which shows a promise to pay (say, by a certain block height or timestamp) up to 1 BTC to Victim (if the block height or timestamp has already passed). It shows that for amounts up to 5 BTC a “verification” message must also be produced that is signed by a third person (owner of 1Friend2…) which includes an identification message from 1Friend1… with a timestamp that is after the “Promise” timestamp. For amounts up to 10 BTC, a second extra verifier is required.

With this in place, Bisq could provide a multisig address into which any trader could deposit some BTC to be used in the event that he has to pay according to one of these vouchers. When that happens, it basically means that guarantor can go to the trader he vouched for to collect.

I like bitrated.com’s model too, but I’m interested in seeing if a voucher-guarantee system might emerge when the technology makes such a thing easy.


#78

@dscotese: I would prefer a long locked up security deposit for new users who want to trade higher amounts. But then it is the question who holds the keys of the MultiSig. With the Bisq DAO we will get a new feature for locking up funds (BSQ) without that problem but the user need to have then BSQ already…


#79

Please see: