Certification for ownership of a bank account

[ManfredKarrer]

In a discussion with the same friend who set the seed for the account age witness idea we came up with a new idea how to protect Bisq users against stolen bank account chargeback scammers.

Goal

We want to add additional protection to the existing protection from the account age witness to mitigate the risk for cases where a stolen bank account scammer has relative low amounts on the stolen account he wants to cash out as the account age witness method does not provide protection for those cases (e.g. amounts below 0.0625 BTC or about 400 USD with current exchange rate). The limits in the account age witness are also harder to change, so in case of a fast BTC price increase the limit in the fiat currency is getting rather high as well and with that it is lowering the protection provided from the account age witness feature.

Our suggested feature for a "certification for ownership of a bank account" is optional and provides additional security if a user chooses to select an offer of such a "certified" Bisq trader or that he decides at his own offers to only accepts BTC buyers as taker who have been certified. The feature is only relevant as protection for the BTC seller as the scammer would be in the role of the BTC buyer.

##Assumption:
A scammer who is in possession of a stolen bank account has only the online banking access but he does not has the physical ATM card nor can he go to the bank branch to withdraw money from the stolen account as at the bank counter he would need to show his ID for verification.

We could use both methods to get a proof that a user is the valid owner of the bank account by requesting the user to withdraw a specific amount to himself using one of those 2 methods.

##Description
We add 2 methods how Bisq users can verify the ownership of their bank account. The user can choose any of the 2 methods, whatever is easier and more convenient to him.

Withdrawal from bank branch

The user goes to a local bank branch and withdraws a predefined fractional amount (e.g. 23.45 USD). He keeps the paper receipt and as soon the withdrawal is visible in his online banking statement he requests from the arbitrator a verification (inside Bisq via a new UI feature). The verification will be done via PageSigner. If PageSigner would not work with the users banking webpage other verification methods are used (e.g. video screen sharing). A scan from the paper receipt can be requested from the arbitrator as well.

Withdrawal from ATM

The user goes to a ATM and withdraws a specific amount (multiple of 10 in a range of 20 -100 USD) and takes the ATM paper receipt.
As soon he sees that transaction in his online bank statement he requests a verification from the arbitrator as described above.

Details

Amounts to withdraw

The amounts are derived from the bank ID (IBAN/BIC,...). The result gets mapped to either a fractional value between 20 and 100 USD (e.g. the national currency the account is based on) or a multiple of 10 between 20 and 100 USD. That specific value generates a kind of fingerprint which makes it very unlikely that a scammer by chance could get such an amount displayed in the transaction history from the victim doing a bank withdrawal by themselves.
The amount for the ATM amount need to be a multiple of 10 as most ATMs do not support smaller amounts. The min. amount will be 20 EUR as most ATMs have that as minimum (need a bit more research if that is correct). The max. amount is 100 EUR (could maybe also be lower like 50 EUR).

Mapping function:

1. Convert the bank ID (IBAN/BIC,...) to a SHA256 hash and convert that to a long number. We use the same data fields as in the account age witness to select the identifying account data fields.
2. Make a modulo 8000 of that long number and divide it by 100 so we get a value in the range of 00.00 to 79.99.
3. Add 20 and use the fractional value for the bank branch version. For ATM version we round to a multiple of 10.

UI

There will be a button at the bank account payment method where the user can request a verification. The first step is that he gets the requested amounts for bank branch version and ATM version. He also gets instructions what he need to do.
After withdrawal and as soon he sees the statement in his online banking transactions history he goes back to the bank account payment method and clicks another button to contact the arbitrator for requesting a verification. That will open a support ticket similar like a dispute case. There he will provide a PageSiger document to verify the transaction or in case that PageSiger is not working an alternative method decided by the arbitrator will be used. In case the arbitrator does not get convinced he can reject the request.
Once the arbitrator has done the verification a signed certificate from the arbitrator will be published to the P2P network and gets matched to his payment account in a similar way we do it for the account age witness.

Create offer and offer book

Any maker of a sell BTC offer can decide to accept only BTC buyers as taker who are certified. For a buy BTC offer it does not make sense to add that option. The restriction option is stored in the preferences and will be remembered and auto-set to the latest selected value when creating another offer.
At the offer book a special icon (with tooltip info) will indicate such offers which require a certified BTC buyer. Not certified users cannot take that offer and will get it displayed greyed-out with an popup when clicking on it which displays context information.
When a certified user is creating an offer his offer will carry a flag to indicate that he is certified (using an entry in extraDataMap in OfferPayload). The validation will be done as part of the trade protocol (see blow).
At the offer book a special icon will indicate such offers where the offer maker is certified.
Even the certification is only relevant in case the maker is the BTC buyer we can show it in both cases to avoid confusion to users who don't fully understand the concept.
There is no restriction that a maker requiring certified BTC buyers need to be certified by himself.

Arbitrator verification process

The arbitrator will get the requested amounts displayed in the request ticket in a new UI screen similar to the existing disputes list. The request carries the users payment account data so the arbitrators application can calculate and verify the requested amounts and display it to the arbitrator.
After verifying with the provided PageSigner doc (or alternative methods) that the withdrawal was done the arbitrator confirms and with that he signs a certificate that the payment account with the specific data has been verified with the withdrawal of the requested amount. The application is publishing that certificate data to the P2P network. The user will see in his payment account that it is now certified.

Verification and data handling

The arbitrator publishes his signed certificate to the P2P network using the hash of the bank ID as key and the arbitrators EC signature of that hash together with the arbitrators index in the pubKey list as value stored in a hashmap.

hash = RIPEMD160(Sha256(identifying bank data, e.g. IBAN+BIC)) -> 20 bytes
signature = sig(hash, EC key)  -> 71-73 bytes
index = Index of public Key in hard coded list of arbitrators keys. Index is represented as a single byte.

Hashmap:
Key: hash
Value: index concatenated with signature

The data size of the hashmap for 100 000 certificates would result in 9.2-9.4 MB. As that data is stored at all nodes and all users can have multiple certificates we have to be careful to keep the data footprint low.
A solution to avoid persisting the signature at all is that the signature check is done at storage time and only valid signatures lead to persisting the hash in a persisted list. That would require only 20 bytes per payment account certificate and also avoids repeated signature checks.
With that model we have a data size of 2 MB for 100 000 certificates which seems a pretty low footprint.

So the published data from the arbitrator contains both hash and signature but the persisted list only gets filled up with hashes after the signature of the data item has been verified.
All Bisq users will receive those certificate data items and they can see if a specific payment account has its hash already in that list.

With that model we can support also the cases when an arbitrator has left as the hard coded list of arbitrator pubKeys will not change.

Similar as with the account age witness the taker cannot verify a makers certificate before actually taking the offer as only in the trade protocol the peers account data are exchanged. But that is not a problem as a maker who used a fake certificate in his offer would get rejected in the take offer process and loses his maker fee as the offer got taken but has failed.

Privacy and centralization concerns

The arbitrator will play an additional critical role by collecting all the bank account data of the certified Bisq users.
The implementation will auto-delete those data after the certification is published but once the arbitration system is fully decentralized we should consider to decouple that role from the arbitrator and leave it to very few operators with high reputation who are trusted to not violate that promise to delete the data (not modified the software).
But ultimately that is a critical problem where not good solution is known.

Using a new role instead of arbitrator

It would make sense to separate the role from the arbitrator even if the persons doing it are carrying out both roles. That topic is subject for discussion and will require a bit more analysis to estimate the effort for separating the roles.

Limitations:

• It will not work with all payment methods if those withdrawal methods (bank branch, ATM) are not supported.
• Theoretically it could be that an account from a certified Bisq user gets stolen. In such a case the protection will not help. We consider it highly unlikely that this will be the case. BTC users are usually not victims of phishing attacks where most of those accounts get harvested. Though we could use the filter feature where the Bisq founder can publish a message which ignores certain certificates, thus even the certificate is in the data structure it would not get accepted from the application.

Wording

We should find a good term for the feature. Certification or verification might lead to confusion with KYC style verification.
Content wise the best description IMO is that it is a "proof of bank account ownership".
Any suggestion for a clear in-ambigious term is highly welcome!

Not intended extensions

Basically by proofing account ownership we would use the verification data also as anchor to a real life identity of the user. E.g. in case of a scam committed by that user the payment account data could be used to identify the user and use that for legal steps against him.
But that model would have several problems:

1. Legal steps are expensive and most users will probably not go that route anyway
2. The arbitrator would need to store all the payment account data forever, which introduce severe privacy problems.

For those reasons it is not intended to extend the suggested feature to such a broader model.

UPDATE:
From the discussions below we found a more privacy protecting model:
The account verifier (arbitrator) will only receive the bank name and hash. He will use a screensharing session instead of PageSigner as most banking webpages reveal bank ID and/or name on the transaction history page. In the screensharing session the user is instructed to only reveal the transaction which shows the withdrawal with the requested amount. Furthermore the bank name (address bar) must be visible.
The hash will be created from the bank ID + a persisted salt to avoid that the bank could find the hashes of their clients.
The verification will be done by the trade peer in the trade protocol where he checks if the hash is correctly derived from the bank ID.
Probably we use additional 2 or 3 relevant digits of the bank ID to reduce the chance that a scammer could trick the system in case he has a own bank account at the same bank as his stolen account.
So that data would be added in the verification process. We will specify that in more details once the basic idea of the proposal gets accepted.
With that modified version the verifier will not learn any identifying data of Bisq users.
The only open issue is that the amount (in case of bank counter withdrawal) is kind of a finger print and banks could theoretically spot such clients as potential Bisq users. Though that has a big risk for false positives for them. If they would get the verification data from the verifier they could identify a client to a Bisq user with it's onion address and it's verification hash. Though a Bisq user can change his onion address when starting a new data directory (as well there is an open issue to support that in the UI).

[ghost]

legit account proof
legitimate account proof
account authentication
...
Question : if a taker is certified thru the above method, could we imagine this certification can stay valid for some time ? 15 days ? 1 month ? more.
Or you feel it's better to have the certification just one shoot ?

[sqrrm]

I know there are a lot of concerns around scams and how to handle charge back risk and I think this could definitely work to mitigate that. The detailed methodology sound more or less correct and would work similarly to account age witness.

However I have some concerns on the direction this steers the project. By adding this kind of account authentication Bisq is acting as some kind of guarantor for these verified accounts, much like a KYC process. By having it as an option it's not unlikely that there would be a pressure to authenticate to even get to trade at all on Bisq if BTC sellers feel this reduces the risk.

The role of 'Account Authenticator' would become another highly sensitive role, perhaps even more so than the arbitrator role and from the point of view of the Bisq network as an organization I think this makes Bisq more fragile. If there is the added possibility of identifying information being included in the authentication process there could also be outside pressure applied on these authenticators to store and share this information with the external agent.

I don't outright say no to this proposal but until I feel convinced it's a good way forward I add a down vote. Looking forward to be convinced.

[alexej996]

Yes, I am also not sure about this. I know it is not really asking for an ID or anything like that, but it still could provide someone with a lot of data on Bisq users.

I am worried that in worst case scenario, that I think is still realistic, we could have vast majority of the network using this feature. This would give someone a possibility to identify most of the Bisq users, which isn't the case currently. I can very well imagine that first thing government agency would do is find a person in this role and make them identify most of the Bisq network. They would probably collect data for a long time before they use it.

This role doesn't just require high trust, but it gives an easy target for someone that wants to destroy privacy of Bisq users. I have to vote a hard no on this one.

[ManfredKarrer]

Thanks for your feedback! I share your concerns and as long we don't get a big problem with low-amount chargeback scams it might not be required at all.

Or maybe someone find a way to avoid the exposure of the bank account data to the arbitrator, but that sounds like a hard problem. It would require something like with Chaumian Ecash where you sign something but you actually don't know what is inside. But you have tested many times other envelopes you received for signing and they had been correct, so you have a high probability that the envelope you sign is also correct. Something along that path maybe could work in our context as well?

[cadayton]

Wouldn't X number of successful trades (Buy/Sell) over a span of time by a trader be a self-certifying way to indicate that person is of good character? I would be willingly to limit all of my trades to only people of good character. Seems we should rate the person and not the person's ownership of a bank account.

You all know the profile of the scams better than I and I trust your methods of trying to deal with it. My bank accounts receipts do not contain the full account data, so not sure how the verification process would work. I would assume any scammer who has comprised a bank account would be in possession of the all the needed account details including online access to the account.

[ManfredKarrer]

@cadayton A reputation system in a decentralized way is very difficult and I have not seen yet a good solution to that problem so far. You have to deal with sybil attacks as well with long con which is basically unsolvable. A trader could set up a few Bisq apps and trade in circles with himself building up good reputation and then start to scam.

" My bank accounts receipts do not contain the full account data": Do you mean that you don't see the full amount of the transaction in the history page of the online banking webpage? That would be weird but Banks are sometimes able to not even fulfill the absolute minimum....
The data which would be required to verify would be the amount and the reference text (e.g. ATM withdrawal) as well a page where the bank ID is visible (e.g. IBAN/BIC).

[ManfredKarrer]

@sqrrm @alexej996
After thinking further I think there is a solution to limit the privacy exposure to non-critical data:

The verification of the withdrawal transaction statement would not reveal identifying data, it would only show that there has been a withdrawal with the requested amount and an expected reference text (in an expected data range - but I left that unspecified so far as I was not sure if it is required).
If we can limit it to that part the arbitrator would not get exposed privacy critical data.

Though then there is the problem that a scammer could make the withdrawal with his own bank account and present that to certify a stolen bank account. The verification of the bank ID was preventing that case. Maybe we find another model which avoids revealing the bank ID but still provides the security that the withdrew amount was from the account to get certified and not from any other account?

I think the solution is to leave the bank ID verification to the trading peer and use the withdrawal amount as a derivative of the bank ID data. It can be used as a trapdoor function similar like hashes. You can derive the same amount easily if you know the bank ID but you cannot derive the bank ID from the amount. Of course the security of that trapdoor function is pretty low but for our use case it should be sufficient.

So lets assume the arbitrator will sign only the amount and will put the hash of the bank ID + amount + signature into the data structure which gets published. He cannot proof if the hash was really created from the account which hash he certified but a trader will do that later and would reject the trading peer if that data was fake.
In the trade process the users are exchanging their bank details, derive the hash and amount from that data, will check if the certificate matches both hash and amount and if the signature is valid. If that all is valid the certified account was correct, if the hash or amount would be different then the peer has tricked the arbitrator by using a different account and the certificate will get marked as invalid.

The privacy exposure is then limited to what the banking webpage displays in the transaction history screen. I just checked 3 of my bank accounts and all show the bank account nr. and 2 also the name. So requiring a PageSigned document does not allow the use to filter out such identifying data. Reducing the requirement to a screenshot would make it easy to blur away such data but also easy to fake the screenshot. A video screensharing could deliver a feasible solution as it is much harder to fake such and still easy to cover the areas which should not be exposed to the arbitrator. PageSigner works on average only at 60-70% anyway so an alternative not 100% secure verification model was required anyway.

There is still a problem though:
The scammer could calculate the required amount for his stolen account and then make a withdrawal of that amount from his own account and present that to the arbitrator. Then the data would be be no detected as invalid in the trade process. To mitigate that we could extend the data set with the bank name and the arbitrator would cross check if the bank name is matching the withdrawal statement.
Then the scammer would need to have his own bank account at the same bank as the stolen account which at least reduce a lot the possible scam cases.
That should be good enough. The goal is not a 100% safe method (though would be good to have) but to make Bisq for scammers not attractive to keep them out.

What do you think? Do you see any issues with the modified model?

[ManfredKarrer]

@HarryMacfinned The certificate would not expire. You only need to do it once.

[ghost]

@ManfredKarrer wrote :

... new idea how to protect Bisq users against stolen bank account chargeback scammers.

Do we have numbers or percentage or estimate about how many chargeback scammers are of this type ? (ie with stolen bank account)

[ManfredKarrer]

We luckily never had a stolen bank account scam so far. I just heard from one LocalBitcoins traders who got scammed 5 times in 5000 trades by such. I fear once Bisq gets more volume that those scammers will try to use Bisq for smaller amounts. Larger amounts will be harder due the account age witness feature.

[sqrrm]

@ManfredKarrer To have the 'account verifier' only checking the bank name and withdrawal amount against the hash would mitigate a lot of the privacy leaks from verification. There is still some information included in the currency and bank but clearly a lot less and perhaps limited enough that it won't hurt.

It might not be easy for users to do the verification without actually revealing the account number and name though, that could be an issue but it would be in the hands of the user. The fact that the verification is less strict would make it less of a must have for BTC sellers and keep the account age as the more useful measure for a good counter party. I like the account age witness feature a lot since it's completely in the hands of the user.

I still have the concerns of where it steers the project having a centralized KYC style feature.

[cadayton]

@ManfredKarrer Just meant the full account number not exposed on the hardcopy but can obtain the full account number and routing online if one knows where to look or from a paper check. Only once in a blue moon do I ever write a paper check anymore.

There are only two guarantees in life right. The long con is interesting. I was wondering why there were such ridiculous offers by people on Bisq. I'm thinking the only person who would ever take those offers is the person(s) who made them. I have a 2% rule. Anything not within 2% of market I ignore.

In using the Bisq-API, I'm able to obtain somewhat of a history of offers made by a particular onion addresses, but that doesn't do much good for sell offers. I'd be ok with a KYC system that destroyed the data after the verification process is complete. If all a scammer has to do is spin up a new install of Bisq and start the process again then that wouldn't be good.

[ManfredKarrer]

@sqrrm We don't have rush to implement that as long we don't have problems with scammers who use low amounts where the account age witness does not help. But it would be good to have a clear plan ready once we need it. Implementation would be not very difficult. We could also implement it but keep it inactive as long we don't see a need, but we would be quickly ready once needed.

I got repeatedly messages from LocalBitcoins traders who say that Bisq's security model will not enough against stolen bank account scammers once we get more volume. It is hard to predict but I also fear that the account age witness is not sufficient. There are for sure many stolen bank accounts sold on dark markets with low Fiat balances on it and we are currently not protected against those.

Security and privacy are not always 100% compatible. If we have a perfectly privacy protecting exchange but there are tons of scammers nobody will use it. Of course we need to take care to have the right balance. 100% security is not possible anyway with Fiat and degrading privacy to just a get a little bit more security is the wrong way as well.

[ManfredKarrer]

@cadayton Unfortunately provable destruction of data is not possible. The arbitrator could also take screenshots in the most simple case.

[cadayton]

@ManfredKarrer Might be possible, the owner of the data remains in control of it and provides access to the arbitrator. The owner then becomes the responsible party for the data not the collector. Just thinking outside of the box here.

[sqrrm]

@ManfredKarrer I think it's good we have the discussion and agree that something might have to be done quickly if the need arises.

My concerns on privacy seems like they might be possible to work on. Regarding the centralized properties of the account verifier role; with less sensitive data being shared the role would be less sensitive. If the role is not as high trust as the arbitrator for example, more people could take it on, still with a bond, and it would be more distributed.

[cadayton]

One method of leaving the owner is control of the data would be to use the secure chat feature with Telegram. The owner then has control to delete any data that is sent and it is documented to happen locally for the owner and to all who received the data. I've not used this feature. It wouldn't be hard to test and verify, if desired.

[sqrrm]

@cadayton The problem with information is that it's always possible to retain copies. If the verifier gets the information there is no way to guarantee he doesn't just remember the information and later write it down. The only way to guarantee identifying information is not gathered is to not share it, which Manfred's latest proposal with hashed account info would handle.

[riclas]

I like the overall idea. It borrows alot from paypal's bank account verification procedure, except it puts the responsibility on the peers. I don't mind this at all, I like the tradeoffs. It will put a lot of difficulties onto a phishing scammer, while not giving the seller the burden of storing KYC private documents. I like the branch withdraw idea the most, since the value can be in cents and allows for a reference to be put, unlike on an ATM.

What if there is no verification agent at all, and you give each seller the responsibility of checking the pageSigner document? The seller was already getting the private information that you agreed to share before, Now he further needs to check that the correct withdraw was done.

I would be totally fine with this as a seller (as long as I can't think of easy tricks a scammer can do), and if i'm a buyer I only have to do 1 withdraw per bank account, seems reasonable...

[ManfredKarrer]

If the peer is doing the verification we would need to repeat that at each trade, which is cumbersome. Otherwise it would be easy for a scammer to make a self-trade and certificate himself.
Also the verification need to meet some quality standards which are not guaranteed if any user could do that.

[riclas]

what if you sign the certificate as a seller? i.e. each certificate on the network would have a list of signatures, and you have to check if one is yours.
IMHO The verification standard should be up to the user. I wouldn't like to be Bisq and get complaints that someone certified an invalid withdraw.

[alexej996]

If I understand the modified proposal, arbitrator would have access to the bank name of the user and the amount he withdrew. If a government agency gets this data for a lot of Bisq users, they could also get the data from every bank on all of it's users and derive a hash for every bank user account. Than just see which ones match and they get the list of only Bisq users.

Even if banks had billions of users, this would take seconds even on a GPU.
Not to mention that if they already have amounts that were withdrawn, they could filter those out.
Maybe they even know the probable time frame when this was withdrawn and might not even need to hash anything.

The problem isn't just the arbitrator himself, even if they are very trusted they could be a victim of a lot bigger more serious attack. I just see too big of risk for too little of a gain here. Security is very important to all exchanges, but Bisq also cares and provides privacy that can not be matched by any centralized exchange, that is what makes this project so important.

[riclas]

That same problem exists for bank transfer disputes. If you accept that risk, you should accept it here too. Thats why we want several arbitrators, so kidnapping the relevant ones becomes unlikely. A seg, 4/06/2018, 16:06, Aleksej Jocic <[email protected]> escreveu:

…

If I understand the modified proposal, arbitrator would have access to the bank name of the user and the amount he withdrew. If a government agency gets this data for a lot of Bisq users, they could also get the data from every bank on all of it's users and derive a hash for every bank user account. Than just see which ones match and they get the list of only Bisq users. Even if banks had billions of users, this would take seconds even on a GPU. Not to mention that if they already have amounts that were withdrawn, they could filter those out. Maybe they even know the probable time frame when this was withdrawn and might not even need to hash anything. The problem isn't just the arbitrator himself, even if they are very trusted they could be a victim of a lot bigger more serious attack. I just see too big of risk for too little of a gain here. Security is very important to all exchanges, but Bisq also cares and provides privacy that can not be matched by any centralized exchange, that is what makes this project so important. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFWUaDollBr__nmJYhANgkG1pC2dM2Mks5t5U0JgaJpZM4UXw49> .

[alexej996]

But arbitrators are necessary for Bisq. I don't think gain of this is big enough to cover the cost.
Furthermore, you only have this during disputes, while this new feature would provide data before trading happens.
We should do our best to decrease the rate of trades going into disputes for this reason and only give arbitrators this information in cases where it is needed to solve a dispute.

It is good to provide features for users that could help them increase security of the fiat side of their trades, but this is a feature which we should hope not a lot of people use. 1 in 1000 trades is a scary statistic, but it doesn't seem to me like most of Bisq users will encounter this issue. It is a quite small price to pay, in my opinion, for privacy.

[riclas]

"Furthermore, you only have this during disputes, while this new feature would provide data before trading happens." No, an arbitrator's machine can be compromised by another entity for a long period of time. The risk is exactly the same here. When sellers start to complain about getting scammed, like they did with venmo, you will see this is not a small tradeoff for privacy. Try to improve the proposal and its tradeoffs, or come up with something else :) 2018-06-04 18:59 GMT+01:00 Aleksej Jocic <[email protected]>:

…

But arbitrators are necessary for Bisq. I don't think gain of this is big enough to cover the cost. Furthermore, you only have this during disputes, while this new feature would provide data before trading happens. We should do our best to decrease the rate of trades going into disputes for this reason and only give arbitrators this information in cases where it is needed to solve a dispute. It is good to provide features for users that could help them increase security of the fiat side of their trades, but this is a feature which we should hope not a lot of people use. 1 in 1000 trades is a scary statistic, but it doesn't seem to me like most of Bisq users will encounter this issue. It is a quite small price to pay, in my opinion, for privacy. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFWUTXAwLtWiNZJusGl7clZa8rK6pNpks5t5XWFgaJpZM4UXw49> .

[alexej996]

Maybe I wasn't clear enough on what I wanted to say there.
I was trying to make a point that if everything goes smoothly traders never need to go to arbitration and therefor never expose their data to an arbitrator, while here they would expose that data as soon as they get verified.

I am certain that they will complain, but I hope it will be rare and that account age witness feature will limit the problem.

Overall I will have to vote no on this one, I just don't think there is a way of fixing it using this method of specific amount to withdraw and sending that data to an arbitrator. This is information that if acquired by a state will lead to deanonymization of the user.

[ManfredKarrer]

@alexej996 Yes you are right with the possibility for the bank to find the hash by checking their user base (though I consider that pretty unlikely). A simple solution for that is what we use in the account age witness: To add a salt to the bank ID data for creating the hash - the bank does not know the salt. The salt will be passed to the trade peer who will be the only one who can verify the hash.

The fractional amount will still be a pattern which might be easy for banks to detect potential Bisq users but first, it is not illegal to use Bisq (and if it is in a county people should not use it anyway as too risky to get caught by an undercover agent) and second, if banks would block user by such a pattern they risk a high rate of false positives. The same is true for the reference text which has also the same weakness of a fingerprint but as well would comes with high risk for false positives for the banks to use that to block users.

Ultimately:
I think the weakest poin regarding privacy is on the blockchain side. The trade txs are a clear pattern to detect and user who don't take care when they spend or fund their wallet are easily caught by chain analysis companies. Bitcoins privacy is unfortunately pretty fragile at least for the majority of users who do not take a lot of care and understand the systems very well.
The only solution mid term I see her is CoinJoin which is loosely planned for some time and off chain transactions which might become possible after the BSQ is implemented.
Using Monero is another option. I have a call with a dev then next days to check out options....

So to update the last proposal:
The user creates a hash from the bank ID (e.g. IBAN) + a random salt (salt is persisted by user).
The app derives from that hash the required withdrawal amount.
He sends the bank name (as in the browser url) and the hash to the arbitrator. They arrange a screen sharing session where the user is instructed to hide identifying data like bank id or name and only reveal the transaction of the withdrawal and the browser address.
The arbitrator signs the hash and publishes hash + signature + index of his pub key (hard coded in app).
At trade the peer will verify that the hash (bank ID + salt) and signature is correct.

The only way how a scammer could trick the system is if he has his own bank account at the same bank. He could then make a own withdrawal and show that to the arbitrator. He use the hash + salt from the stolen account for the hash which the arbitrator signs. In a trade the peer will correctly verify the hash and the scam is undetected.
But the likelihood that the scammer has the same bank is rather low and it would require that the scammer understands the system very well.
We could even mitigate that by requiring to reveal the first 3 characters of the bank ID in the verification. So I think that is not a critical problem. I would actually add that requirement to the proposal above.

I fully understand your concerns but in fact I think that the current arbitration model has much bigger problems in that regards (planned in the fully decentralized version to get resolved).
It is true that there not all cases ending up in dispute but also that feature is optional and not all need to use it. Furthermore it is mainly relevant to be used by BTC buyers.

I followed a bit some forum/reddit threads the last weeks and had the impression many LocalBitcoins traders are considering to move over to Bisq but many don't trust the security model (many did not understand it as well) and the chargeback topic came up repeatably.
Lets assume we get a healthy wave of new user and our volume multiplies and with that scammers get attracted to check out how they can abuse Bisq. With the current situation a stolen bank account scammer with 300 USD on the account can easily use Bisq to cash out and the victim likely suffer a chargeback. As one on the forum said those scammers are often not "full time professional" scammers but people in poor counties who use any opportunity to make money they can find. 300 USD is a lot in many countries and there can be many such people and stolen account for sale on the dark markets (would be interesting actually to check that out).
So I would not underestimate that risk, but of course we will only know once it happens.

I just want to be at least prepared to react quickly if we would get into such a situation and not risk to lose all the gained volume because of a wave of scams which would damage Bisq's reputation. It takes very long to build up good reputation but can get lost very fast and it would take long time to recover.

But I am very happy to see those critical inputs and don't want to push that too hard if I don't see strong support. I just think the privacy issues are solvable and the additional task for the arbitrator is a price the security improvement is worth it.

[ManfredKarrer]

@riclas
Re: "what if you sign the certificate as a seller? i.e. each certificate on the network would have a list of signatures, and you have to check if one is yours."
You mean that you sign only your trade peer and if your repeat the trade with the same you can be sure that the is not a scammer?
That would be very cumbersome and will not help you with most traders you have never traded before.
Also there is no communication path between the traders atm.

[riclas]

Why would it not help if you can certify the withdrawal for yourself? I want to remove the arbitration entirely from the process. Just make each user responsible for his certifications, and help him by storing signed certificates for future trades. What do you believe is very cumbersome in that process? i'm down for that work if it means i'm trading safely. If this works as i'm seeing, I might actually borrow that idea for my own clients who don't want to share documents... 2018-06-04 19:38 GMT+01:00 Manfred Karrer <[email protected]>:

…

@riclas <https://github.com/riclas> Re: "what if you sign the certificate as a seller? i.e. each certificate on the network would have a list of signatures, and you have to check if one is yours." You mean that you sign only your trade peer and if your repeat the trade with the same you can be sure that the is not a scammer? That would be very cumbersome and will not help you with most traders you have never traded before. Also there is no communication path between the traders atm. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFWUX9QQ08x169W-4XQUeliB1BN2Dglks5t5X6-gaJpZM4UXw49> .

[ManfredKarrer]

@riclas If the peer certifies then you can only trust it if you do it yourself. Any other peer could have been a sockpuppet from a scammer. So that will only work the same way we use our "local reputation" system where you see how many times you traded with a peer. Is or sure something useful but I think its rather limited. To have it globally would be much more useful.
If the verification process of the arbitrator does not include any private data I really don't see a biug problem in that.
Beside that it is cumbersome if you trade with 20 peers and need to do that verification 20 times. An the peer get verified by his other traders as well. You need to agree on a screen sharing session and that makes the trade experience not more smooth. Beside that you need to explain the user why and how to do that which adds more mental transaction costs to the process.

[ghost]

@mpolavieja
See the last proposal of @ManfredKarrer #76
It seems to overlap with your idea.

[mpolavieja]

I don´t know if I should open a different issue for this. A completely different approach would be to allow users to sign their IBAN account details with a digital certificate (could be issued by a National Government or any other entity). The simplest way for doing this is would be by including a Bisq screenshot of the SEPA account details into a pdf file and signing that pdf with the digital certificate and attach that pdf file to the Bisq user profile (An updated acrobat reader can handle all this). It would be up to the trading peer to trust that digitally signed pdf or not.

I know this sounds horrible regarding privacy, but i think that at worst it would only add the ID national number to the data we are already providing when setting up a SEPA account in Bisq. And anyway, the ID national number could be a trivial thing to find once you have full name and lastname from your trading peer.

This approach has the risk that the scammer has managed to steal both the bank account details and the private key from the victim´s digital certificate, which is not that unlikely. But if a scam happens in this context, the legal risk of the BTC seller, the Bisq founders / DAO is reduced as it would be very clear that there are measures in place to verify identity to reject scammers, and that the security problem was on the victim side, not on Bisq or on the seller side.

As a general comment, the more messages and more mechanisms that very clearly show that bisq users and devolopers fully reject scammer activity, the lower the legal and regulatory risk for everyone.

We should aim not to have a perfectly secure system (which is obviously impossible) but a system that is clearly significantly superior to fiat (which should be achievable). In this respect, collecting scanned copies of national ID cards as most centralized entities do is an extremely reckless procedure as they can be re-used by scammers if stolen. Digital signatures on the other hand are not reusable.

[mpolavieja]

A much more user friendly approach would be that instead of a user-made pdf file (which maybe could be used to inject malware), Bisq handles all the signing by requesting a signature to the certificate repository of the user´s machine, and then embeds that signature into the user profile. But from my experience as a digital certificate user I suspect that would be a rather muddy development.

However, if it is not that muddy and that development is feasible, a more private approach could be to just sign individual transactions instead of the profile to overcome young account limitations.

[flix1]

This certification system, if I have understood it correctly, is redundant if we implement a distributed reputation system. Account verification is worse than account reputation. Having previously done honest trades with an account (+ time) is a better guarantee of honesty than "verifying" the account before having done a single trade.

I am also concerned about the KYC slippery slope, even if this is optional.

[ghost]

I'm also concerned/horrified with using government tools to do our job.
Bisq is by itself a network of trust, if we have to use/issue certificates, it would seem me so much natural
to search that in our own network, than to return in governmummy's skirts.

And in a general way, a negative reputation system concerning 0.1% of the users is more efficient and fair than a positive reputation system with concerns 99.9% of users in order to catch the 0.1% bad ones. Positive reputation system is used by govs, that says a lot I find.

[ManfredKarrer]

@flix1 The important part is that the certificate issuer is not aware of Bisq / BTC. So there are no privacy concerns with that. I simply proofs that some 3rd party has verified your real life ID and you can proof that cryptographically without revealing additional data to the peer. As there it is not likely that this becomes a very widely used features I think there is also no risk that the optional feature becomes semi-mandatorsy as otherwise nobody would trade with you. It would be part of a bigger set of features where user can choose from. Time, money or real life ID are options to provide additional security.

All that refers to the new idea posted by Manuel about using the existing certificate infrastructure not the the topic of that proposal.

[mpolavieja]

The thing is that government certificates are free and people are already using them, so it is an already working deployed infrastructure and very cheap for the users if they already have the free certificate. It is thought not as a redundancy but as an alternative to the reputation system, so users that want to trade quickly could skip the reputation system delays by duly identifying themselves to their trading peers (which they are already doing by providing their SEPA details).

The initial idea was using a decentralized ID system (a la uPort), not using government digital certificates. But since there is no working decentralized ID project, the only available infrastructure are private or government certification authorities.

Private certification authorities based on the cloudsignature consortium https://cloudsignatureconsortium.org/ which are equally valid than governmental issued ones are probably more secure as they require 2FA using One Time Passwords for each signature. But private certificates have a cost around 20€-50€ a year. Spanish government certificates, for example, do not require 2FA to sign.

Anyhow, both government or private certification authorities are centralized, I don´t like them that much. But from a practical point of view, they could be useful. I am working on a more formal and detailed proposal, I expect to have it ready this week.

[mpolavieja]

@HarryMacfinned regarding negative reputation system I am not sure at all it is a good solution for the specific problem of fiat stolen accounts. Even if you have very few events of this kind the impact is terrible as it will most likely impact active traders and market makers and if that happens one or two times, the bank will most likely tell them to stop that activity or close their account. If Bisq consistently loses market makers that´s very bad. The reality is that fiat is problematic all on itself.

[luisgdelafuente]

Hello people,

May be you should have a look at the Estonian Digital ID. I use their ID-card for years now and its a great and trustable way to use online banking, among many other services.
https://e-estonia.com/solutions/e-identity/id-card/

The platform is robust enough to allow some very interesting apps on top for additional mobile verification; eg Smart-ID: https://www.smart-id.com/

I know, all of this is not decentralized and has nothing to do with reputation. But I can tell you: the combination of those 2 tools is the safest way to validate bank account ownership and management. May be that´s the path to follow for this specific need.

[mpolavieja]

I´ll include a reference to estonian ID system in my proposal. I have to say, though, that I agree a lot with @HarryMacfinned that BSQ bonding is the way to go. It could lead to a quite strong OTC fiat-btc market for power traders (given that banks leave bisq transactions alone).

If strong liquidity is achieved through BSQ bonding, that could be a good incentive for smaller traders to make an effort to overcome the UX hassle of BSQ bonding. However very little traders and casual buyers could be pushed out of Bisq even with that liquidity incentive.

So an account verification procedure could still be useful for some kind of "second layer market" where a Bisq node could choose to allow very small traders and casual buyers to trade only with him if their accounts are verified. So in that sense, exploring account verification procedures is still useful even if not used within Bisq core users.

[flix1]

Thinking about this a bit more... why do we need to rely on governement issued digital certificates?

We are in the Bitcoin world after all.. we could come up with our own verification system in which peers who have successfully traded with a certain payment account sign on the Bitcoin blockchain or make a microtransaction to a Bitcoin address to vouch / upvote an account.

This would be simpler than using official digital certificates, scalable to anywhere in the world and relatively simple to do. It would combine reputation, with Bitcoin cred, with a permanent record on a public Blockchain.

The difficulty lies in doing it while not revealing any sensitive information about the traders and their bank accounts... but I'm sure that the people who have come up with Bisq and the BSQ couloured coin can manage it! We can even use the BSQ explorer as a tool to register this decentralized reputation and charge BSQs for the initial verification.

https://explorer.bisq.network/

So you would have the following BSQ transaction types:
-Transfer BSQ
-Pay trade fee
-Verify account
-Upvote account
-Downvote account
-Report account!!!

[flix1]

Example of the idea above:

Alice wants to verify her fiat account with Bisq to get the "verified" badge on all her offers.

1. Alice pays 100 BSQ to Verify account to an address that cointains a hash of that bank account IBAN.

2. Every subsequent trade performed with that payment account will allow Bob (seller) to burn 10 BSQ and "verify" Alice's account through a simple upvote transaction.

3. If a trade is unsuccessful Bob can also end the dispute mechanism by making a Downvote Account transaction for 50 BSQ or a Report Account for 100 BSQ.

4. Arbitrator Charlie can also report / downvote an account by making a BSQ tx to the address.

5. Just by looking at the BSQ address related to a payment account, we can see the full history of successful or failed transactions, upvotes, downvotes, reports and bans.

This decentralized reputation would show up as a "verified" badge next to the offers created by Alice using that account. Maybe also include a 1-10 score.

This system is not as powerful as BSQ bonding, but it is better than simple reputation which can be gamed with fake trades. Most importantly it ties reputation not to user or identity, but to payment account. It also allows very fast reporting of accounts that become compromised. It's not user reputation or age, but payment account reputation, age and history.

I would be very glad to hear criticism of this idea as well as ideas on how it could be implemented.

[ripcurlx]

Isn't that pretty much what was suggested in #78, just without BSQ involved?

This system is not as powerful as BSQ bonding, but it is better than simple reputation which can be gamed with fake trades.

It could be gamed as well, it just gets more costly (10 BSQ for upvote after fake trade). You could add additional checks if each single trade has based on the payment method a minimum time frame between start to end to detect fake trades more easily. But still this can be faked when done properly as well.

The idea of this and #79 is to shortcut the slow verification part based on successful trades.

The problem with having this complete trading information in the public is that it reveals more about the account to everyone. We might have a similar problem with the BSQ bonds.

[flix1]

The problem with having this complete trading information in the public is that it reveals more about the account to everyone. We might have a similar problem with the BSQ bonds.

It does not need to... No revealing information about the account would be public. Only the Bisq network would associate a particular offer to that account's reputation address. The only thing that other traders would see is the end result in the reputation badge/score.

[flix1]

The problem with #79 is that using government certificates is limited to a few countries and at any point they could change the system on us. Adoption would be minimal. BSQ or BTC based verification/reputation could work anywhere in the world.

Most importantly it does no require identity verification, which opens up more vulnerabilities.

[ripcurlx]

The problem with having this complete trading information in the public is that it reveals more about the account to everyone. We might have a similar problem with the BSQ bonds.

It does not need to... No revealing information about the account would be public. Only the Bisq network would associate a particular offer to that account's reputation address. The only thing that other traders would see is the end result in the reputation badge/score.

What I meant was, that if the BSQ address where all transactions take place is public you could see the trading history of this user. Not the exact amounts and details, but the frequency and timing. Maybe there is a way to cloak this and still to make it verifiable for everyone.

[mpolavieja]

@flix1

Proposal #79 suggests government certificates because it is the available infrastructure as of today. There is a quite significant share of the population in Europe that use it regularly to interact with the administration (taxes, etc). But the core idea is digitally signing the bank account details with a digital certificate where the ID has been attested, no matter if the certificate issuer is decentralized, private or government.

Your proposal above is very interesting. I´d say that while it is true it is physically and legally decentralized, that is, censorship resistant, it would still be logically centralized (the BTC blockchain is logically centralized). A little privacy could be leaked (trades, etc), but I don´t see a big problem with that.

[mpolavieja]

@flix1 Could it be possible that the upvote is much more expensive than 10 BSQ and it is paid by the user being verified instead of the verifier user? (using a presigned txs and another signature is needed for burning). The cost of faking would be much higher but would be free for the honest verifier.

I understand that the BSQ amounts should be fixed as a ratio of BTC amounts to neutralize BSQ volatility.

As a side comment, I find interesting the idea of finding additional utilities to BSQ such as this verification / reputation procedure.

[ManfredKarrer]

@flix Thanks for your idea regarding a BTC based reputation system.

A few notes:

• A decentralised reputation system is very hard and as far I know none exist beside WoT. So if we work on that we should be aware that we are trying to solve a hard problem. Maybe we can solve it as we have certain conditions in our favor (bank account is a scarce resources, BSQ or BTC payment add costs against sybil atacks,...) but we should not underestimate the complexity and difficulty. It has to be really solid otherwise it just creates false feeling for security and is more damaging as it helps at least once Bisq's liquidity is bigger so more sophisticated scammers will try to find ways to trick it.
• The solutions we are aiming for should be able to be implemented relatively fast. Resources are limited and other important work like the new trade protocol are in the pipeline as well.
• The Bisq DAO should be considered like the BTC scripting system as very hard to change or extend once deployed. All is possible but cost/risk to benefit ratio need to be kept in mind and consensus systems are very complex and dangerous to change.
• We have some tools built into the DAO which can be used to leverage new use cases. Specially bonded reputation and proof of burn. Proof of burn comes with a signature feature so that the owner of the burned BSQ can proof his ownership as well as a hash which can be used to link to any other external data (like account age or account data). Also the bonded reputation contains a hash which can be utilized.
• We know how to protect privacy from the account data but still are able to verify it during the trade. Basic idea is to use a hash so nobody can read out real information and during the trade when traders exchange the payment account data they verfy each other.
• Dealing with Fiat is dealing with legacy systems and I am not sure if if purely cryptographic systems are sufficient to handle that. I think a very interesting strategy is to piggyback on existing infrastructure which does not add new requirements and does not add privacy weaknesses. E.g. using a bank account comes with certain KYC preconditions which we can utilize without doing KYC on Bisq, we inherit the banks KYC (or governmental KYC in case of the certificate) without gathering data and without forcing the user to do KYC for Bisq as well as not providing any Bitcoin related information to the authority doing the KYC. Real life identity is a free scarce resource everybody has and is the main tool used in our normal life/economy. The alternative is using Money but that has high costs (need to cover max. damage).
• The certificate idea does not reveal private information to anyone beside the trade peer.
• Using the blockchain has privacy issues regarding chainanalysis. Using any blockchain system will restrict the user that he cannot start over with a new wallet to improve privacy and performance (old wallets with many txs get heavy with SPV mode).
• We have to be aware that any reputation is based on some sort of identity and sticking to an identity weakens privacy. There are already now some weaknesses which we should get rid of (e.g. signature key is used for account age witness and if you don't want to lose your account age when starting with a new application directory you have to take that signature key over and leak some inforation to your old trade/offer history). When we extend the importance of the account age we make it even harder that users can start over with a completely fresh app without connecting back to the past trade history. Not sure if it is possible at all to avoid that problem if any reputation is involved. Using BSQ bonds is probably the only way to avoid those problems but then you have to take care to not leak privacy on the blockchain side (e.g. by sending BSQ from the old wallet to the new wallet).
• Using the blockchain for up/down-voting has higher costs as using the P2P network. If you consider high future tx fees (10-30 USD) then it adds even more problems to that approach.
• We should consider an off-chain trade protocol as the most likely future-proof trade protocol and the protection tool should be therefor aligned with that. Using the blockchain would add costs and privacy leaks.
• Banning a scammer should be considered exceptional (we had very few cases in 3 years until recently) and to use a more centralized but more flexible and faster system like the filter tool we use now seems justified IMO. This current filter tool can be ignored by the user, so the potential risk for abuse is limited. Using the DAO with voting would be too slow.
• If you give users a tool for banning or downvoting you end up in new attack scenarios. There might be users who don't want to pay but who would be very valuable with their feedback, so those will not have influence. A loud minority could cause the main effect. There are new attack scenarios (e.g. you see a marketmaker which competes with your offers and you start to downvote him to kick him our of competition and earn money from trades with your offers at higher spreads). Reputation is easier destroyed as earned as we know from real life. That can be abused like it is in smear campaigns like it happened to Julian Assange.

The problem with #79 is that using government certificates is limited to a few countries and at any point they could change the system on us.

Yes, I agree the problem with limited regions, but to cover SEPA region is already a huge gain, it's our main market atm.

I don't consider a change of the certificate system a realistic problem. Once governemnent have rolled out something after many years it will stick around for very long time. It is all standardized cryptography as far I understand (have not looked into details).

Most importantly it does no require identity verification, which opens up more vulnerabilities.

It stricly need to be considered optional. I don't see much vulnerabilities. As long you are a citizen who is able to open a bank account you should be able to get that certificate. You do not reveal anything to the certificate authority how you will use that certificate in Bisq.

Regarding up/down voting:
One alternative approach could be to use a part of the security deposit which will be either paid back to the trader or donated to the BSQ donation address in case the peer consider the peer has not fullfilled his trade contract. So that way the peers would rate each other how satisfied they have been with the trade performance. They don't have much motivation to give it to the Bisq donation address as they do not directly benefit - at least not more as to have another satisfied Bisq trader. This payouts could be used then as reputation from peers. But it is important to not consider that as secruity feature but as a tool to indicate good traders who pay fast and don't cause problems. For real scammers it is too easy to game. But I think main concern is that it would leak privay on the blockchain as well would not work with the off chain trade protocol. It would also add another interactive step, slowing down the trade execution.
Just wanted to share - maybe it inspires for another new idea....

[reipichu]

One big failing on the part of the banks, which is one of the main causes of our problems with stolen accounts, is that they are presumably not providing 2FA for bank transfers.

My bank's online banking requires 2FA for every transfer (regardless of size), so it would be difficult for a scammer to steal money by bank transfer even if they had my login details. They would need access to the 2FA method also.

Knowing that some banks require 2FA and some do not is something that we could possibly use to our advantage, if we could compile a list of banks (ie routing numbers etc.) that are less vulnerable to account theft.

Compiling this list reliably would be a challenge in itself, however it could be a means to mitigate some of the problems we are having by directing users to sign up accounts with banks in their country that cause fewer problems for Bisq as they have more secure systems. Users of those banks could benefit from reduced verification requirements for higher trade limits.

If this sounds like an idea worth exploring then I am happy to create a separate proposal for the idea of maintaining a list of "more secure banks" that we could use as part of the input to whatever verification and reputation system we choose to use.

[mpolavieja]

It is good idea and it has been discussed before I think, but the problem more than compiling is mantaining that list and who is in charge of that task.

But as @flix1 has proposed in #93 this could be somehow built on top of Bisq instead of within Bisq, so users could use that information at their discretion for their local whitelisting (once local whitelisting is implemented).

[chimp1984]

@cbeams @ripcurlx Could you please ban @user718141 ?

[cbeams]

Already done last week.

…

On Jan 4, 2020, at 11:55 PM, chimp1984 ***@***.***> wrote:  @cbeams @ripcurlx Could you please ban @user718141 ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[mpolavieja]

Closed as stalled. Account signing in version 1.2 has somehow implemented this feature.