Same onion address, different people

What payment methods is that peer using, if you don’t mind me asking?

I don’t know either if this is an issue or not. (If people invent new usages, that may be interesting).
But, I would however recommend to be cautious and to investigate a bit.
And preferably avoid doing many of such transactions if things are not well understood and if you have doubts.
If the offers are too good (is it the case ?), this may be a warning bell.

When the DAO will be released, the contributors will have to vote on the reimbursement demands.
A user who has been scammed N times by a same onion may perhaps have some difficulties to be reimbursed for the whole batch.


The payment method is SEPA

He´s been always a taker buying 3%-4% above market price. The problem is that if he is a taker I cannot avoid him taking my offer, unless I completely block him.

@Homard what possible the attack would be possible here?

It is a bit suspicious that he is always a taker and that it is always the same payment method.

This peer may very well be scamming other people to send funds to accounts that he gets from Bisq so he can get the BTC in return without risking his/her anonymity. The risk for OP is that police reports could be filed against the OP and funds could be requested to be chargebacked due to theft.

PS: You might want to consider at least temporarily putting that peer on the ignore list. After a while if you don’t have any issues with your bank over these transactions and if the peer doesn’t get network wide ban, you can remove him from the ignore list.

1 Like

This might be a friend of mine. Because he is very knowledgable with BTC and he has friends that are not very knowledgable but either want to get their first BTC and learn about it or are interested in purchasing products and goods that are only availabe for BTC purchase like Openbazaar for example.

And he is willing to help his friends in that way as to at least get their BTC safely. Unfortunately governing bodies and regulations make it difficult for specific markets (in specific countries) to establish themselves publicly. Good thing we have markets like Openbazaar.

1 Like

You can block peers by onion address in the settings.

I and @keo have looked up for disputes with that onion address and nothing suspicious was found and the users was also one time a BTC seller and used another payment methods as well. So at least that he was not always the BTC buyer decreases the risk that he is a “stolen bank account scammer”.
The possibility that he does trades for friends is not unlikely.

I think he is back again. He is the one with several buy offers at 5000€ (market price is 4500€). Different names from netherlands and germany.

Finally this peer is a fraudster. My bank has freezed 2 of his payments because the sender has reported that his account was stolen. Do not take any offers from him!!

Ok, arbitrators need to be aware of this activity and it is good to keep a list of all the bank accounts this person used.

@keo @arbitrator1

1 Like

Hi, I’m new here. I got the same problem: a user with onion address kqsaevkgu7apgzlt.onion with whom I’ve traded 4 times, he used 3 different names/nationalities/IBANs, he was always BTC buyer and payed with SEPA. My online bank (Bunq) shutdown my account after a charge-back request that failed because I already moved the funds out of the account marking as suspicious activity on my side (!), the another chargeback went throught. A third payment hasn’t been charged-back yet but it could any day, for the forth payment my other bank warned me that they’ve received a chargeback request and asked for confirmation (finally someone reasonable!) which of course I’ve denied making myself available to show that a trade happened and I have delivered the digital good in good faith, I hope they’ll just reject the request, don’t know yet, the warning is just from this afternoon.
Of course I’ve banned the address, but now I’m not really sure I should accept SEPA/Fiat anymore. I’ve received another payment from Transferwise which I checked consider all payments final so I’m happy with that, but how can I know when a transfer is safe to unlock the funds? Maybe Bisq/arbitrators should add on top of the payment initiated/paymente received events also a grace period (say 1 week) to prevent or reduce the chargeback risk. I see it as a very big problem, users will get scammed and will leave Bisq in disgust.
Does anyone have any suggestions?

For fiats.

  • Mitigate your risks (aka don’t trade N times in a row with a same fully unknown counter-party. That’s exactly the kind of imprudent behaviour the scammer is fishing)
  • Only trade next time with a counter-party when previous time have closed successfully AND the chargeback time has passed,
  • be cautious with young accounts
  • if you are yourself a young user, be cautious with yourself. Don’t use Bisq at 150 miles/hour when you just joined one week ago. Take the time to understand how things work
  • make your due diligences, do a little search in the appli and on the forum concerning the onion you want to trade with. Btw, it’s always a good idea to read the forum/blog/slack/docs and keep informed about the appli and the news of the ecosystem.
  • in case of doubt, search for more safe offers, if not better offers, renounce to trade and wait. Good offers arise every day.
  • etc (certainly other precautions to add)

If you cross most of the above points, you should reduce your risks significantly.

For cryptos, there is no chargeback, so the above risks doesn’t exist.

Bisq devs are aware of this issue and have some ideas to reduce this problem.
Hopefully we’ll see some implementation in the next or n+1 version.

1 Like

Thanks @Homard for the quick and helpful reply. Surely I will follow all your advice in the next trades.
I still have a couple of noobish questions, please bear with me:
If I’m placing an offer how do I check the counterparty beforehand? (excepting banning in advance those I’m not happy with already). Seems it’s safer to pick the offers rather than publishing them? Can’t a validation option be introduced before the offer is picked up?
Second question, is there a standard chargeback time I can feel safe with or it depends on the banks and is fully discretional (like could charge back after 6 months? :frowning: )
Thanks again for the support, hope this thread is useful also for other newcomers

Yeah, you are right, taking an offer gives you a bit more control who you are trading with, but validation option when someone takes your offer could have it’s own problems.

Someone could setup a really good offer and decline everyone automatically. This would be a form of spam in this case.

I don’t know how SEPA chargebacks work, but if you wait for a max trade period before confirming the payment, the other person has more time to do a chargeback while your BTC is still safely locked in multisig. This would be useful in case of stolen bank accounts doing chargebacks once the owner notices the payments.

We could possibly consider prolonging the max trade period for SEPA trades.

1 Like

Yes, I understand the spamming implications of offer taker validation. Maybe a solution would be to enrich the profile information with the ratio of declined trades over the total trades (one user counter per trade, to avoid multiple counting); in this way it would be visible who is systematically rejecting offer takers. Still has some attack surface, but that’s not a bad solution in my opinion.

Extending the trade validity for SEPA could mitigate the problem but also worsen the user experience if the counterparty is irresponsive, so I’m not really sure, I was further reading the chargeback request conditions for some Mastercard cards connected to SEPA IBANs and you can even charge back 120 days after the trade, so it doesn’t sound like the prolongation would be a scam-killer.

On the other hand it would be useful in my opinion to give an unlimited amount of time for a user to signal a chargeback/problem reporting a user, undergoing a documentation check with an arbitrator that could mark the profile with a warning that would flag them for say 3 months. This would result in a sort of reputation score attached to the identities, for example I would see in the profile "Account Age: 50 days § Total successful trades: 30 § Lost disputes (last 3 months): 4 § Rejected offer takes (last 3 months) 2/5 (40%) § Post-trade warnings (last 3 months): 3 ".

Another idea would be, given the profile scores above, if the user does not match a certain quality level according to some metrics, it would enable the possibility for a validation check before the taken offer is accepted by the person who offers it.

Sorry I’m mixed some topics together, but I think there is room for improvement and I really appreciate how quickly and friendly the Bisq community and involved people react and support.



Yeah, I guess there could be a limit to how many takers could attempt to take an offer before it becomes invalid. However malicious takers can take down competing offers by trying to take them with unwanted/suspicious accounts and increase the counter of rejected takers when the maker rejects them. Still the offer maker does have some control over this, so it is better for him to have a choice then not at all.

It is a valid solution, I think, but it is easily gamed so to not be very useful if implemented this way. Still I guess better than nothing, I don’t know.

As for the flagging of users that initiate a chargeback. These users are straight up banned by the devs. These have been very rare cases until now, so each one was handled manually by the developers who contacted affected victims directly.
I am not sure what the future holds for Bisq. Maybe we will be able to limit the chargebacks again and these imperfect automatic solutions would be unnecessary.

The rating is easily tricked in a decentralized anonymous system. Successful trade counter is useless (even dangerous) since malicious users can easily take their own trades with a different PC and complete them successfully. Account age would be useful UI feature, since it is already implemented in the clients, but not displayable to the users. The other suggested metrics are just the ones we discussed above, so they would have their own complications.

Please see Manfred´s proposal on this and my response:

Really good advice for newcomers.