Certification for ownership of a bank account about proposals HOT 67 CLOSED

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.

from proposals.

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

from proposals.

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.

from proposals.

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

from proposals.

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

from proposals.

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.

from proposals.

Example of the idea above:

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

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

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

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

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

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

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

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

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

from proposals.

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

from proposals.

from proposals.

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 ?

from proposals.

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.

from proposals.

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?

from proposals.

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.

from proposals.

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

from proposals.

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

from proposals.

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

from proposals.

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

from proposals.

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

from proposals.

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

from proposals.

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

from proposals.

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

from proposals.

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

from proposals.

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.

from proposals.

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

from proposals.

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

from proposals.

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.

from proposals.

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.

from proposals.

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.

from proposals.

from proposals.

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.

from proposals.

from proposals.

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.

from proposals.

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

from proposals.

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

from proposals.

from proposals.

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

from proposals.

from proposals.

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.

from proposals.

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.

from proposals.

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

from proposals.

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.

from proposals.

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.

from proposals.

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.

from proposals.

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

from proposals.

from proposals.

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

from proposals.

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

from proposals.

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.

from proposals.

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.

from proposals.

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.

from proposals.

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.

from proposals.

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

from proposals.

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.

from proposals.

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

from proposals.

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.

from proposals.

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.

from proposals.

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

from proposals.

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

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

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

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

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

from proposals.

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.

from proposals.

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.

from proposals.

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.

from proposals.

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

from proposals.

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

from proposals.

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.

from proposals.

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

from proposals.

@cbeams @ripcurlx Could you please ban @user718141 ?

from proposals.

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

from proposals.