Certification for ownership of a bank account

ManfredKarrer commented 6 years ago

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:

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

Legal steps are expensive and most users will probably not go that route anyway
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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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

ghost commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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

cadayton commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 notifications@github.com 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 https://github.com/bisq-network/proposals/issues/23#issuecomment-394388502, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFWUaDollBr__nmJYhANgkG1pC2dM2Mks5t5U0JgaJpZM4UXw49 .

alexej996 commented 6 years ago

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 commented 6 years ago

"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 notifications@github.com:

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 https://github.com/bisq-network/proposals/issues/23#issuecomment-394444223, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFWUTXAwLtWiNZJusGl7clZa8rK6pNpks5t5XWFgaJpZM4UXw49 .

alexej996 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 notifications@github.com:

@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 https://github.com/bisq-network/proposals/issues/23#issuecomment-394455876, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFWUX9QQ08x169W-4XQUeliB1BN2Dglks5t5X6-gaJpZM4UXw49 .

ManfredKarrer commented 6 years ago

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

riclas commented 6 years ago

Sure, as I said, the certification is only useful for each seller. However, the same withdraw can be used by the buyer for all certifications, since what we want to certify is the bank account. Yes it's a local system for me as a seller to certify buyers I want to transact with.

I don't see much of a problem either, but if you can take out the arbitrer from the certification, the better...

I was not thinking of doing screen sharing, I was thinking of the first approach, providing a pageSigner approved page. If you can show the details of the withdraw (bank account and name) to the seller, I don't see any issue with it in this scenario. A buyer only has to certify his account once, a seller has to certify all buyers he wishes to transact with. Seems like a good tradeoff to me, since this is for the security of the seller.

2018-06-04 23:01 GMT+01:00 Manfred Karrer notifications@github.com:

@riclas https://github.com/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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bisq-network/proposals/issues/23#issuecomment-394514389, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFWUVpWhe7AwTZbhzMlvljewIh3ulL_ks5t5a47gaJpZM4UXw49 .

d4ndo commented 6 years ago

Implement some rating system. 1-5 Stars. Worked on silk road should work on Bisq. There will always be fraud - and there is no 100% protection. If you're afraid of the little scammers, you didn't have an account on Mt. Gox. Security vs freedom.

ManfredKarrer commented 6 years ago

Seems we got the first stolen bank account scam: https://bisq.community/t/full-reversal-on-zelle/5705/

sqrrm commented 6 years ago

What do we know about the bank account in this case? Was it a young account age? Anything that stands out to differentiate the trade? We might well have to look at this proposal seriously now.

ManfredKarrer commented 6 years ago

The bank told him the peers bank made the reversal because of fraud and he need to ask the other bank. For sure the other bank will tell him nothing...

cbeams commented 6 years ago

I didn't follow this proposal closely, and while it's quite outdated now (my bad) there is a lot of conversation here and it's not clear to me whether I should close it as rejected or stalled, or to do something else with it.

@ManfredKarrer could you weigh in as to how you see this proposal now, and where you want to go with it? Thanks.

ManfredKarrer commented 6 years ago

I think it got kind of stalled and even if accepted would lack of dev resources to implement it. I would love to keep it open just to have it easier to return to it. I think it is still a valid option for improving security.

ManfredKarrer commented 6 years ago

I think that idea is not further developed. I will leave it open still as it might still be interesting to read up and might lead to future continuation or extension.

luisgdelafuente commented 6 years ago

@ManfredKarrer , can you please develop a little bit more why a decentralized reputation system is not appropiate here?

riclas commented 6 years ago

reputation is gameable and bisq doesn't want to tie identity to nodes.

luisgdelafuente notifications@github.com escreveu no dia quarta, 10/10/2018 à(s) 19:09:

@ManfredKarrer https://github.com/ManfredKarrer , can you please develop a little bit more why a decentralized reputation system is not appropiate here?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bisq-network/proposals/issues/23#issuecomment-428674064, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFWUYDD5QAfATNWBZyZzbpgIVdDoGh5ks5ujjfdgaJpZM4UXw49 .

luisgdelafuente commented 6 years ago

gameable: not if its calculated on top of reputation, and as a result of transactions chain...
reputation does not need to be tied to real identity, and its not an intrinsically centralized idea at all (talking about self sovereign reputation)

ManfredKarrer commented 6 years ago

@luisgdelafuente To build up long-living identities (even if not tied to real life id) it comes usually with privay problems. E.g. using trade history everyone can see how much u have traded. The best what can be done IMO is building a kind of WoT where you get reputation from a network which whom you have traded. But that is a pretty complex challenge and it needs to be also easy to understand and use. PGP WoT shows that even it it works technically it does not mean that it works socially (if its too complex to understand for the majority).

If you know any solid concept or project which it working on such a system let me know. I think OpenBazaar had invested a lot of effort in that area and I think they gave up on it (not up to date, so might be wrong - point me to resources if so).

mpolavieja commented 5 years ago

How about allowing buyers to be able to optionally pledge a long term security deposit (2 of 2 multisig with an arbitrator) that could get frozen or seized if the network's users / arbitrators suspect he is a scammer? The security deposit could only be withdrawn after 20 or 30 days from the last fiat payment. Sellers could configure their settings to not to trade with buyers that haven´t pledged a long term security deposit, or if the security deposit is lower than X BTC.

If the buyer is honest and legitimate user, I am sure he would not have problems on recovering his deposit. It the buyer is a scammer I highly doubt he would ever pledge a significant security deposit.

There is a risk if the arbitrator becomes unavailable that the deposit could not be recovered, so maybe it is possible that the arbitrator's private key of the 2 of 2 multisig deposit could be somehow shared amongst two arbitrators.

ghost commented 5 years ago

@mpolavieja See the last proposal of @ManfredKarrer https://github.com/bisq-network/proposals/issues/76 It seems to overlap with your idea.

mpolavieja commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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.

bisq-network / proposals