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.
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.
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.
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:
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?
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ā¦
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.
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).
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.
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.
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.
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.
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 ;-).
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?
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!
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.
@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ā¦
I did my first Zelle trade today on Bisq and it went well but Iām somewhat concerned about chargeback risks as been discussed extensively in this thread. I think that the one way to mitigate chargeback risk is to have a user focused rating system which will provide additional reassurance that the user is a safe counterparty. I dont see anything like that in bisq and didnāt see this aspect being explored in this thread. The added benefit would be that it would also help minimize the exposure of the community to scammers because the rating will be impacted quickly signaling users that there may be a problem.
Please let me know if Iāve missed an existing feature that performs the above task. Iām still new to the platform. I know that there is a payment account counter but this is a lesser indicator because accounts can be created, aged (without any activity) and then used for fraud. It would seem to me that a counter of number of completed transactions would be a better indicator. Moreover, the platform doesnāt seem to have any mechanism for sellers to set a minimal payment account age (trade volume) so that they can have some control over the risk they are taking.
Please correct me if Iām missing some key features or anonymity considerations which prevent such a safety score indicator at the user level.
On a related topic, what is the consequence for a fraudster if they exploit the platform to run their scam? Can moderators suspend their participation some how? If so, the above user or activity volume indicators could provide additional motivation for users to act ethically.
Thanks in advance. Wish me luck with that zelle transfer; I will give it a few days to āconfirmā before attempting another one.
I hope the final point wonāt be āwell now we know that KYC has a purposeā 
Imo this is the most important issue of all, because if youāre not careful every precaution you make could take away from the essence of the user experience.
What about use www.civic.com to verifiy users identity?
I think the user could pay for it and I donāt think itās expensive.