Certification for ownership of a bank account

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

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

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.

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.

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

Example of the idea above:

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

Alice pays 100 BSQ to Verify account to an address that cointains a hash of that bank account IBAN.
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.
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.
Arbitrator Charlie can also report / downvote an account by making a BSQ tx to the address.
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.

Isn't that pretty much what was suggested in https://github.com/bisq-network/proposals/issues/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 https://github.com/bisq-network/proposals/issues/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.

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.

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.

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.

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

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

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

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.

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

@cbeams @ripcurlx Could you please ban @user718141 ?

Already done last week.

On Jan 4, 2020, at 11:55 PM, chimp1984 notifications@github.com 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.

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

bisq-network / proposals