New requirement for payment accounts with charge back risk

Putting the plain hash into the offer would violate privacy as anyone who knows the bank account (bank,…) could make the hash and find out who is the offer maker.
I doubt that the victim of the stolen bank account would be a Bisq user. I think most of those victims are technically not very skilled and Bisq and Bitcoin users typically are. But if we get the mainstream we might reach that group one day ;-).

Well, not necessarily. In an IBAN code could be eliminated the two digits of country, the two digits of control, and another more any and even so the false positives would be very rare (In those rare cases you can open a ticket and the problem would be solved quickly)

If someone knows the account number and wants to verify if it corresponds to the hash of a transaction, the information obtained would only be clues, never evidence, since that hash could potentially belong to many other accounts

I made this proposal because some exchanges like Poloniex inform you by email of each operation and this is reassuring, because you know that if your account is used you would know it. It is what I intended with this proposal, although I agree that its usefulness would be limited, but I think it would give a good feeling.

In any case, I believe that the only completely secure way that could allow many means of payment would be to include the signature of the transaction document with an official digital certificate. Is it so difficult to obtain this certificate in other parts of the world?

Ah good point with the SEPA format (not aware of the details). I think it still can work with the additional secret as your app knows it and therefore can match the trade.
Yes I understand now better your motivation (Poloniex example).
Will consider it once we work on that!

Suppose I identify myself with a private key by signing the matching public key. I can then also sign a statement saying that I vouch for the owner of a different public key with an amount of some currency (BTC, for Bisq). The statement means that if an obligation (in default) signed by the other owner is presented to me, I will pay it.

Of course that opens me to the risk of the other owner’s key being compromised, but my statement can be more complicated to address this. If we establish a good protocol for the structure of the statements, they will become machine readable. The current implementation of Bisq puts the single arbitrator (Manfred, most of the time) in control of everything (when trading partners disagree), but it doesn’t provide any vouching - only a kind of escrow.

If we build out the vouching, then knowing someone in the network would give newbies some recourse in the case of cheating.

A simple example:

<identification owner="1XYZabc123..." type="ID" timestamp="2017-07-30T03:17:00Z" ...>Signature1</identification>
<voucher guarantor="1XYZabc123..." for="1Friend1..." max="1" currency="BTC">Signature2</voucher>

Signature1 is the signature produced by signing the opening identification tag (with attributes) using the public key represented by the owner attribute. The “…” in there is for attributes providing other data that the signer wishes to prove, such as real-name, physical-address, telephone-number, etc. The signer could then take a picture of themselves holding a copy of the signature, like I did with my phone number at

Signature2 is the signature produced by signing the opening voucher tag (with attributes) using the public key represented by the guarantor attribute.

A voucher could be tiered so that for higher amounts, the potential victim may be required to verify that the friend’s key has not been compromised:

    <guarantee guarantor="1XYZabc123..." for="1Friend1..." currency="BTC">
        <max amount="1"/>
        <max amount="5" verifier="1Friend2..."/>
        <max amount="10" verifier="1Friend3..."/>

This XML represents that the owner of 1XYZabc123… will send up to 1 BTC to anyone (“Victim”) who can produce a (timestamped) “Promise” message signed by 1Friend1… which shows a promise to pay (say, by a certain block height or timestamp) up to 1 BTC to Victim (if the block height or timestamp has already passed). It shows that for amounts up to 5 BTC a “verification” message must also be produced that is signed by a third person (owner of 1Friend2…) which includes an identification message from 1Friend1… with a timestamp that is after the “Promise” timestamp. For amounts up to 10 BTC, a second extra verifier is required.

With this in place, Bisq could provide a multisig address into which any trader could deposit some BTC to be used in the event that he has to pay according to one of these vouchers. When that happens, it basically means that guarantor can go to the trader he vouched for to collect.

I like’s model too, but I’m interested in seeing if a voucher-guarantee system might emerge when the technology makes such a thing easy.

@dscotese: I would prefer a long locked up security deposit for new users who want to trade higher amounts. But then it is the question who holds the keys of the MultiSig. With the Bisq DAO we will get a new feature for locking up funds (BSQ) without that problem but the user need to have then BSQ already…

1 Like

Please see:

I did my first Zelle trade today on Bisq and it went well but I’m somewhat concerned about chargeback risks as been discussed extensively in this thread. I think that the one way to mitigate chargeback risk is to have a user focused rating system which will provide additional reassurance that the user is a safe counterparty. I dont see anything like that in bisq and didn’t see this aspect being explored in this thread. The added benefit would be that it would also help minimize the exposure of the community to scammers because the rating will be impacted quickly signaling users that there may be a problem.

Please let me know if I’ve missed an existing feature that performs the above task. I’m still new to the platform. I know that there is a payment account counter but this is a lesser indicator because accounts can be created, aged (without any activity) and then used for fraud. It would seem to me that a counter of number of completed transactions would be a better indicator. Moreover, the platform doesn’t seem to have any mechanism for sellers to set a minimal payment account age (trade volume) so that they can have some control over the risk they are taking.

Please correct me if I’m missing some key features or anonymity considerations which prevent such a safety score indicator at the user level.

On a related topic, what is the consequence for a fraudster if they exploit the platform to run their scam? Can moderators suspend their participation some how? If so, the above user or activity volume indicators could provide additional motivation for users to act ethically.

Thanks in advance. Wish me luck with that zelle transfer; I will give it a few days to “confirm” before attempting another one.

I hope the final point won’t be “well now we know that KYC has a purpose” :grin:
Imo this is the most important issue of all, because if you’re not careful every precaution you make could take away from the essence of the user experience.

What about use to verifiy users identity?
I think the user could pay for it and I don’t think it’s expensive.

I believe whenever feasible there should be a privacy alternative offered to KYC.

The way PayPal is able to do ‘instant’ bank transfers (i.e. spend from a linked bank account) is by having a linked credit card authorize a security hold, while PayPal pays for the purchase out-of-pocket. Once the bank transfer has completed successfully, the hold is released.

full explanation here (the PayPal Moderator’s post).

An analogous system can be used to effectively secure chargeback-able transfers. The buyer simply submits a BTC security deposit equal to the purchased amount of BTC (prior to performing the transfer), which will get refunded after a certain time period. This time period may be determined by algorithm, based on (1) the buyer’s history, (2) the payment method’s statistics - i.e. its historical time periods for chargebacks, and (3) the seller’s accepted level of risk.

A buyer may avoid this deposit by using one of the available means of reputation or identity verification, if he is able to do so.

People who live with their relatives do not have a utility bill in their name. Also all people do not have a social media, or had time or interest for such a thing. To me, making social media a requirement to use bitcoin would be sad.

KYC is a slippery slope. Yes it has a purpose. It also feeds an entire industry of people paid to circumvent it. And I believe there is almost always a viable alternative.

I hope bisq will continue to allow sellers to manage their own risk if they desire, i.e. accept buyers w/o identification, the way Paxful does currently (though this may be changing).

One way sellers on Paxful do this is by lowering their offer rate (of bitcoin per payment value) to offset their statistical risk of chargebacks.

This is another viable alternative to kyc. It avoids the need for an equal security deposit, as the seller is able to profit over the long term based on their known ratio of good customers. He is able to compete with kyc-requiring sellers by serving a larger market. If the seller finds he is unable to maintain a profitable ratio or protect himself legally, then he can adopt one or more of the verification systems/options, and let someone better-equipped take a go at it.

anyway those are my thoughts


Why not allow the seller to choose the security deposit for the trade, ranging from $0 - equal value, and a deposit-refund time period ranging from 0 - 1 year. The buyer can either accept those terms, or do some verification to reach a better set of terms (as stipulated by the seller), or move along.

This gives the seller a toolset of ways to manage their risk, and I think would be wonderful

Hello Manfred, hello community,

have you considered to ask the IMHO best expert in this kind of security problems, Bruce Schneier ( ?
He is strong pro Open Source and always interested in new technologies.
I’m pretty sure he would have good proposals for Bisq if Manfred is able to “sell” the request for a free consultation right. He might even blog about Bisq and its security problems and reach thousands of security professionals !

1 Like

Waow, it’s so sad you need to have this brainstorming just because the banking system is designed the wrong way. Satoshi invented a trustless system and so should remain Bisq.

Here are some comments:

  • The beauty of Bisq is its privacy so you need to keep that as the first criteria. Using social media as 2FA really sounds like a poor workaround compared with the overall greatness of Bisq.

  • Relying on the seller to do KYC would be really bad. As a buyer, I would never send my ID to a seller even if it gets watermarked. Also, a scammer can easily Photoshop/GIMP a selfie and trick a forensic analysis (such as by scanning a printed version of an edited picture + editing the metatags. If you really want to go with KYC, I think @leo idea to have the user rely on a specialized KYC service of its choice is the least worst (the other party would judge if the chosen service is reliable or not).

  • I don’t understand how a decentralized reputation system can work. Darknets is the home of scammers so I think it’s not that hard to create a good reputation using fake transactions

I realize this topic is about stolen bank accounts but I hope it is less a risk now that we are in 2018 and 2FA is mandatory for all EU banks at least. In fact, I am more concerned about triangular scams (such as the one described at Are there scams in Bisq?) which is very common on localbitcoins. I understand the current protection on Bisq is to limit the amount sent via SEPA based on age but I have 4 banks and only 1 of them let me see the sending IBAN when I receive a SEPA (the 3 others just give me the name of the sender). So a triangular scammer could very well have a fake IBAN age the necessary time (so he can buy any amount) and have its victim sending me the SEPA and I would have no way to control… Also, storing a hash of the IBAN’s in Bisq might be a leak of privacy if you consider that a Belgian IBAN has only 16 characters from which only 7 numeric characters are random (16 - 2 for “BE” - 5 for the branch which is a shortlist - 2 for the validation code). That makes a short list to bruteforce with John the Ripper.

Fortunately, Bisq is not used by scammers yet but I don’t see why it won’t happen if nothing changes. Maybe you should consider pausing the fiat reversible methods until they get reliable. In the meanwhile you could focus on new solutions such as cash deposited via ATM and enhance the crypto to crypto trades (by using the blockchain for step3 for example, see Why not use blockchain for step 3?).

It is just a personal opinion and I am sorry if I sound harsh, especially because I only criticize but I don’t bring new ideas. I had a good thought about it but I couldn’t find anything really good. I just think that Bisq is the best solution out there so we all need to protect it.

Thanks for your feedback!

That thread was motivated by a chargeback case more then one year back. We had been initially worried that it could have been a bigger damage as it actually was (was a single case). So we tried to brainstrom all kind of possibilities without considering any of those more closely, thinking what could be done and what would be the consequences. We are very aware that privacy protection is the core of Bisq and any compromise in that area would be fatal. Though if security is compromised Bisq would be dead anyway.

Regarding the account age witness feature: The hash of the bank account data are created with an additional salt which is only revealed to the trade peer, so brute force should be not an issue here.

Unfortunately the Fiat side is very problematic in 99% of the payment methods, but as Bisqs main mission is to provide a privacy protecting Fiat gateway to Bitcoin we cannot just limit that to those very few less hurting payment methods (thought those have usually other problems like F2F) and we also don’t want to limit Bisq to crypto-crypto exchange. To improve that is on our roadmap (e.g. automate altcoin trade with API) though.

Hello Manfred and thanks for your answer. I wish you all the best with Bisq. Good to know about the salt in the IBAN hash. Quick question though, doesn’t it allow a scammer to do multiple small transactions while its account is limited by age?

Yes, of course. Limits are only per single trade.
However, not dealing with big trades means that arbitrators will have time to react and less damage can be done before they do. That is the idea at least.

Stolen bank account scammer increase their risk that the account theft gets discovered when doing more transactions. So our assumption is that those criminals prefer to cash out in few transactions and Bisq becomes not attractive to them.

1 Like

I had my first encounter with fraud on bisq through Interac (bank to bank transfer in Canada). I was selling some BTC and apparently the buyer was using a hacked account to make the purchase, I found out about a month afterwards and after about a month of back and forth I finally convinced my bank not to confiscate the funds from my account and help restore my service. Now I’m struggling to find a way to transact in CAD that I am comfortable with. A reputation system like this would be awesome.

However, I wouldn’t trust a 0 rep user to do any transaction with them, no matter how small the limit is. As I have learned through my ordeal is that at least in Canada, Interac will cut you off at any sign of fraud and it is up to your bank to convince them that you are not involved. So basically if you are caught up in fraud, you are at the mercy of a bank employee to fight for you and an Interac employee to believe in you, which is too much of a gamble for me to attempt again.

Also, if the order book is thick enough, a bad actor could in theory spam multiple small offers before they are discovered.

I like the idea from wodry to hold the BTC for a month before releasing it for the first transaction. I’m not clear what the purpose of wait time from account creation to first paying / buy offer is though.

Also, there is still a risk that a bad actor can get you in trouble with your bank even if they don’t benefit from it monetarily.

Having the ability to choose if you’re willing to take that risk (accepting 0 rep trades) would be nice as well.

Oh sorry to hear that! But good that you could avoid that the Bank externalized their poor security to you!

Reputation is problematic: Such a scammer could do several trades, earn good reputation and then 1 month later you get the chargeback. Also it hurts new honest users as they will find it harder to find traders.

The broken system of banks by allowing chargeback cannot be 100% solved in an exchange unfortunately. The rate of chargebacks is luckily super low (2 reported cases with Zelle and now yours - the Cashapp/Venmo cases have been because it was a mistake to add those insecure payment methods), so it seems that the protection in place works good enough.
Keep in mind that any additional friction like delayed payout or reputation will lower trade volume as many users will not be willing to take that disadvantages. To find the right balance between usability and risk exposure is a challenge. To get 100% safetly against chargeback we need to wait until Fiat is not required anymore. F2F trade might be an alternative but that comes with other risks and inconveniences.

Thanks @ManfredKarrer, unfortunately Canada is becoming more and more crypto hostile. Especially with the recent QuadrigaCX fiasco.

I agree, a scammer can do a lot of damage before they are discovered but I think a mix between your initial proposal and @anon10998290’s suggestions could do some good in mitigating some of the risk involved in trading on Bisq (at least it would make me feel better :)). Even if initially the reputation system is just a soft (non-enforced) system and we give users the choice on what risk they are willing to take.

Just to reiterate your previous discussion since I’m digging up such an old thread:

  1. User A is a new user and they create an account. Their account # and nonce is hashed etc. Following @anon10998290’s examples, their account is now flagged Red

  2. User B is a market maker seller of BTC. User B has a choice on offer creation to allow Red users to take their offer. Here there is a bit of a barrier to entry for new users, but at least User B has a choice. Perhaps it is worth the risk to them if their margin is high or the trade amount is lower etc.

  3. User A manages to take User B’s offer, after a month of elapsed time and User B has not reported a chargeback, their account is marked Orange (not sure how this would be done)

  4. User C != User B and User C is a market maker seller of BTC. User C has a choice on offer creation to allow Orange users to take their offer.

  5. User A manages to take User C’s offer, after a month of elapsed time and User C has not reported a chargeback, their account is marked Green. I think a green level user is a pretty safe user to deal with for any risk appetite (maybe?).

The age requirement is easier for a scammer to work around than the proposed reputation system (the scammer I encountered had an age of 244 days when I dealt with them). This also gives the users a choice of risk they are willing to take and to customize their offers according to risk involved. Of course this doesn’t have to apply to all payment methods. It could just be applied to those with the highest chargeback risk, I think it is preferable to outright removing a payment method when we reach some threshold of reported issues/chargebacks.

EDIT: I overlooked the issue of a scammer gaming the system by creating multiple accounts and creating fake transactions to promote/validate a scam account. To work around the issue, just off the top of my head:

Require User B and User C in #2 and #4 to be “Green” status themselves, otherwise, their transaction will have no effect on the status of User A’s account.

Initially, all current accounts are Green. Users you have previously transacted with can claim a chargeback which will demote your status (I don’t know if this is possible/desirable). The thought is: any existing scammers will be weeded out of the system eventually if they somehow circumvent the safeguards.

Also, when User B or User C transacts with User A, they are in essence vouching for User A. I think it may have been mentioned in this thread, but perhaps we can include a mechanism in the DAO for the ability to vouch for a user account without actually requiring a transaction:

  1. User D is a voucher with a green status. He can lock up the maximum transaction amount of an Orange user in BSQ in order to vouch for User A.

  2. User A is the vouchee. After User D vouches for him/her they are now Orange if their transaction gets charged-back etc. both User D and User A are demoted.

Maybe have a black status as well for accounts that have proven to be scammers.

Would this be feasible?