[bisq-network/proposals] Certification for ownership of a bank account (#23)

Sat Jun 2 17:07:58 UTC 2018

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 newly suggested feature 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 who have done that verification. The feature should be only relevant as protection of 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
User goes to a local bank branch and withdraws a predefined fractional amount (e.g. 23.45 USD). He keeps the paper invoice 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 uses (e.g. video screensharing). 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).
Again as soon he sees that transaction in his online bank statement he requests a verification from the arbitrator. A paper receipt from the ATM should be taken as well.

##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 (or 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 from the victim doing a bank withdrawal by itself.
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 true). 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 decide what are the identifying bank data.
2. Make a modulo 8000 and devide by 100 so we get a value in the range of 00.00 to 79.99.
3. Then add 20 and either use the fractional value for the bank branch version or round to a multiple of 10 for the ATM version.

### 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 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 verification. That will open a support ticket similar like a dispute case. There he will provide a PageSiger doc to verify the transaction or in case that PageSiger is not working an alternative methods decided by the arbitrator. 
Once the arbitrator has done the verification he gets a signed certificate from the arbitrator and that will get attached to his payment methods 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 be remembered and auto-set to the last selected selection 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. 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 method data so the arbitrators application can calculate the requested amounts and display it to the arbitrator. 
After verifying by the provided PageSigner doc (or alternative methods) that the withdrawal was done the arbitrator confirms and with that he signs a statement that the payment methods 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 (using Sha256 wrapped in RIPEMD160) and the arbitrators EC signature of that hash together with the arbitrators index in the pubKey list as value stored in a hashmap. 
All Bisq users will collect all those data items and can see if a specific payment account has its hash in the map. If so they take the signature and the index to lookup the pubKey in the hard coded list of arbitrator pubKeys and verify if that signature is correct. 

With that model we can support also the cases when an arbitrator has left as the hard coded list of arbitrator pubKeys do 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 de-couple that role from the arbitrator and leave it to very few high trusted operators who would not violate that promise to delete the data (not modify 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. As the arbitration system will get a larger redesign anyway this aspect gets another context. But not sure if the additional effort for introducing a new role (e.g. new registration process) is worth to separate it. But that can be decided once the proposal is worked out in more details. 

## 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!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/23
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20180602/061004c9/attachment-0001.html>