Delay payout for Fiat trades if buyers account is fresh #77
Comments
Implements bisq-network/proposals#77 If fiat trade the buyer need to have an min required account age, otherwise the payout will be delayed.
|
I think this is great as a short term measure, but because a scammer could easily fake a fiat trade and wait 31 days, I think it could be a good solution that the account age remains at 0 days as long as the payment confirmation is done by an account that is younger than March 15 2019 (i.e. clearly after the activity of the recent scammer begun). For more security it could be even required that the age remains frozen at 0 until X different payment confirmations from X different old accounts have been received. Ideally it would be good to require also that the old account has been several times a BTC buyer from at least other X different onion/accounts. Don´t know if this is possible. All this departs from the assumption that all transactions happened until March 15 2019 are legitimate and users that participated in those transactions are trustworthy. I am totally aware this is not solution for reputation and by no means is near perfect, but since we are already relying on the account age, this would make the account age significantly more reliable. Once this measure is in place, the accounts that reach 30-40 days would be much more trustworthy, and the age requeriment for payment confirmation could be dynamic, but we would have a problem with the accounts created between March 15 2019 and the date that this measure is put in place, some ad-hoc solution would be needed for those accounts. EDIT: Another assumption in my suggestion is that scammers deem their stolen account as valuable and they don´t want to expose them in a place where they have the risk of the victim discovering it without having any profit at all. Right now, that risk is 0 in Bisq for the first few transactions. |
|
The idea above could be improved by departing from a more manually curated group ot trusted bisq users. In any case the core idea is that there is some kind of initial source of reputation from a specific group of users that through real trades grant reputation to new bisq users. Of course, this only works under the assumption that reputed users are doing real fiat trades. |
|
I like that existing users will have a higher protection against scammers, but on the other hand this measure further raises the barrier for all new Bisq users. Not only they need to have bitcoin in order to start using Bisq, they would also need to wait a month before their first trade materializes. In my opinion this hinders wider adoption. Instead of delaying finalization of the transaction, the transaction can go as normal, but there can be additional (higher) security deposit for new users that is held for 31 days and only released if no issue arises. |
|
I agree that all this raises the barriers of entry for new users, but at this stage security is more important and I think we really need that scammers see Bisq as a place of wasting stolen fiat accounts. Regarding the amount of time that the user has to wait, this could be discussed because having a delay of just 2 to 4 working days would be a very significant deterrent for scammers, as the risk of wasting a stolen account would be much higher than it is right now where the BTC are released instantly as the payment is confirmed. Having a delay greater than 4 working days up until 31 would improve security, but not so much that from 0 seconds to 4 days. |
|
It is not just a risk for a scammer to waste their stolen accounts, but to lose their buyer security deposit as well. If an offer has a high security deposit and a long delay for payout, the risk can be unprofitable for a scammer. A month should be enough for anyone to notice their account made unauthorized transactions, so I think this is a good solution. Only weak spot that remains is the patience of the scammer. If they are not in a hurry to cash out, they can simply wait 31 days for their account to age without making any trades. Sending any fiat is risking the owner finding out their account is compromised. This delay feature doesn't have to be dependent on the account age witness. They can be two separate security options provided by Bisq that can be used together or apart to increase the security of trading in Bisq. You can make an offer with a payout delay of a month for all accounts and a custom buyer security deposit so high that it is too risky for a scammer to take your offer. This is pretty much fool-proof solution as it is simply not in the interest in the scammer to trade with Bisq (at least with these offers). |
|
I didn´t mention the loss of the security deposit because it is obvious. Indeed, I have even proposed long term security deposits (more than three months) as an optional "certification" procedure for new users (see here: #23 (comment)). I just wanted to highlight that we should consider into the equation that the stolen account has some value for the scammer. Regarding the delay and the account age, I fear very much that if we underestimate scammer patience, the account age parameter could become dangerously missleading. As I explain above, I believe account age should start to increase only if payment has been confirmed by an old account. |
|
OK, but I still don't see what the problem is with having the trade go without delay, but keeping a high security deposit for a month. Also, I think this measure should be applied not only to accounts with age < 1 month, but in general to the first X trades. This solves the problem with scammer patience. |
|
I agree that security deposit is the best measure although IMO it is a higher barrier of entry than just waiting. Moreover, if the security deposit is lower than the amount traded the scammer would still profit. If the security deposit is higher than the amount traded, the barrier of entry for legitimate users is higher. I suspect that releasing the traded BTC and the security deposit on different dates would require a different trading protocol than the current one, at least for those first transactions with new users. The problem with scammer patience would not be fully solved only by withholding the security deposit for the first X trades, as the scammer can easily fake those first X trades by confirming non-existent fiat payments setting up another Bisq user and using it as the seller trading peer. |
I think these points are key, otherwise, with the current system, a scammer could act alone in aging his own accounts and we're back to square one. An extra layer of proving integrity could be doing in-person transactions: if a new trader initiates a bank wire or cash deposit in-person at a bank branch to a counterparty with considerable account age, that is a good sign...2-3 of those, even better. |
|
Thanks all for the input and I agree to most. One important restricton in current situation is that we need a solution which is wasy and fast to deploy/implement. Any change of the trade protocol would fall outside that. Also splitting security deposit from trade amount does not work as all funds is in the MultiSig and can only be spent in one go. One aspect to consider is to make the default pretty strict but offer features where users can "buy" reputation e.g. by locking up BSQ in a bonded reputation. Using trades with old accounts is for sure a good idea but I am not sure if there is a easy solution how to implement that. |
|
From what I've seen on darknet markets it seems stolen accounts go for 2-5% of the account balance. Some of the comments from sellers also indicate that the accounts are rather sensitive to age. That's only one way these scams happen I'm sure, but it's an indication of what we're dealing with. Currently we need to make sure Bisq doesn't become a way to cash out these accounts and I think the restriction to payout only after accountagewitness is 31 days old is an ok solution. It's likely more than needed to deter the scammers that care about the freshness of the accounts the try to defraud, but better be cautious and later reduce that time limit. The difference between just blocking new accounts for 31 days and letting them trade and then wait until day 31 for the bitcoin is that there is a chance for defrauded accounts to notice and alert the bank during that time. I don't know which is better but I'm ok to try this way. New users might find it less than ideal to be out fiat with no BTC to show for a month. They could of course wait 31 days but many people don't read the rules and will likely end up surprised. |
I was thinking on just checking the account age from the seller, if it is older than X, then the account age of the buyer can begin to increase (or after N payment confirmations from older than X accounts). But I guess that since Bisq is opensource, this could be easily changed in the sourcecode by an advanced scammer. To avoid this, maybe it is possible to achieve the same result by some cryptographic function based on the seller account age, so the payment confirmations from old accounts are cryptographically verifiable without leaking privacy? To avoid surprises with waiting periods, pop ups are very useful. From Manfred´s proposal and screenshots, it looks like Manfred has taken that into consideration. As a general comment, I think that to help users onboarding and bearing with waiting periods it would be good to somehow make clear that Bisq cares a lot about private property of Bisq users and also non Bisq users, so these measures are for the benefit of all. If this message is understood and valued, it will attract honest fiat users on the long term. For the fiat users that don´t care about private property well... does the Bisq community want them on board? |
|
@sqrrm There will be popups at each step where you enter a trade so if the user is not completely ignoring all he should be aware. But of course it decreases usability. One thing to consider it that you freeze the price, so if price rises you get the old good price when you finally receive the BTC.... |
|
The account age witness data are just a hash created out of the important bank details (IBAN,...), a salt (random number) and a signature. Those data are stored at each node and are only added if the date stated in the witness data is inside a small time tolerance window so you cannot back-date. I am not sure if there is a way to add a feature that old witness data can be used to sign something for new users as the public key is not part of the data and so others cannot verify it later. The model is designed for 2 trade peers not for any additional - that would require that the payment account details are exposed as well as the pubKey for signing which is only part of a direct P2P connection as it is the case at a trade. But I will think about it if there is way... |
|
Btw. here is another older proposal which was intended against other scams (not stolen bank account scams): #27 |
|
@ManfredKarrer wrote
I don't know if it is easy to implement. But it seems an interesting idea. In the same vein, I think that the deposit % used by makers could be better emphasized in the offers, in order to push makers to use high deposits (see bisq-network/bisq#2761 ) |
|
We were talking a lot about delays here #77, but I understand comments about delays are better placed in this thread. @HarryMacfinned, @flix1, We should take into consideration also that the delay not only is a strong deterrent for scammers, but it is also very helpful to undo the harm thief has made to the victim of the stolen account. As much as I don´t like banks and fiat currency, I believe it is important that Bisq cares about everyone´s private property, no matter if they are Bisq users or not, or if they are BTC users or not (even BTC haters). Indeed, being more resilient to fiat scams than fiat itself would show the superiority of building on BTC over fiat. Delay is also a good measure to keep Bisq under the radar of regulators because if most harm is undone, chances are lower that Bisq related chargebacks scalate up within Bank's organizations and up to regulators and police / law enforcement. As we all know, it is sadly usual that regulators are very willing to hunt down a system even if fraud transactions are just a tiny fraction of overall transactions. |
|
Despite my ux-related misgivings, I agree that this needs to be done. However: -Delay should only be applied to payment methods with chargeback risk. (So for example UK Faster payments does not allow payments to be reversed and so should not be delayed, same for Revolut, etc). -A delay of up to 30 days will be a big turn-off for new users. We should have an exception for low amounts to allow newbies to play around with Bisq and start using it. For example for trades of 0.001 BTC the risk of fraud is extremely low... it is just not worth risking a stolen bank account to do such small scams. But for new users it will allow them to start trading on the first day and learning how to use Bisq. |
|
Fully agree with ux-related misgivings. That´s why alternatives to allow to fully override delay such as BSQ bonding or account verification are very interesting (those alternatives are also a UX hassle, but at least they are just one time hassle, not for every tx).
|
|
@mpolavieja @flix1 I agree that the key issue is the reporting of fraudulent payments. It's a risk to the user, both monetary and inconvenience in possible getting accounts closed and getting flagged as a bad bank user in general (we're not too far from the Chinese reputation system). It's also a risk to Bisq itself if it attracts the wrong kind of attention from those that might want to shut it down. The low amount trading sounds like a good idea as long as it's low enough that no scammer would even try it. That kind of small scale trading could also be used as a way to verify accounts apart from users learning how the system works. They could also get their account verified that way by trading with a reputable peer and after 31 days the account would be verified, as discussed in #78. |
Agree -- I think we can say any fiat method that's not cash-based will need to be limited. Zelle in the US is hard to reverse, perhaps like Faster payments in the UK, but accounts can still be stolen. So face-to-face is good (like Manuel said) but also other cash-based methods like money orders, MoneyGram, Western Union (via cash), etc should not be subject to any of these limits either. All others would have to be, I'm afraid (except for low amounts, which I agree is a good idea). |
This is interesting. I guess it is possible to require the payment confirmation from a trusted user without the delay if the amount is very low. I can think of the following drawbacks:
Regarding drawback number 2, it would be unlikely that the scammer takes this strategy as the chances of being discovered and wasting the stolen account are quite high. But beware!!! This risk is not explicitly for this low quantity exception because wihtout it we would still have that risk!! If the intention of the scammer is not cashing out but to get the stolen account validated through small payments, then the scammer wouldn´t really care about the delay, nor about cashing out the little BTC, nor about losing the tiny security deposit. |
|
@mpolavieja About case 2, I agree. What do you think is a reasonable size for these small transactions that would be small enough that scammers wouldn't risk it and new users still get some value out of it? |
|
@sqrrm First of all, I think we should consider the possibility that small transactions can allow a spam attack where an ill minded hacker that wants to hurt Bisq or a Bisq hater could buy a low balance fiat bank account (i.e. below 20€) on dark marktes and use it to make a lot of small payments to trigger stolen account reports from victims and cause nasty problems to the relationship of honest BTC sellers with their banks. Some banks, like N26, very quickly close client´s accounts without asking at the slightest doubt of fraud or even just because unusual transactions or transactions they just don´t like. I don´t want to seem paranoid. I am aware the attack described above would be a really ill and stupid spam attack. Very unlikely, I hope, but still a possibility. Just wanted to raise it. To answer your question I´d say that if we decide to disregard both the scammer trying to validate accounts with small tx (unlikely) and the above spam attack risk (also unlikely) the minimum of 0.001 BTC proposed by @flix1 is ok, in that case the tiny security deposit, a minimum trading fee, and mining fees (which will always apply), would contribute a little bit to avoid both risks. If on the opposite we want to actively minimize those risks, I´d suggest at least a minimum trade size of 0.005 BTC and also a minimum security deposit of 0.005 BTC + mining fees (i.e. a potential total loss above $50 for each tx for the dishonest user). But please note that I don´t have any strong opinion on these figures, not really a very educated guess. |
|
This old spreadsheet of payment methods might be useful: BISQ TECH TREE 1. CURRENCIES, PAYMENT METHODS and LIQUIDITY
Anyone who wants is welcome to update it, add more risk paramenters, etc.. |
|
Proposed delay function from account age witness (no reputation factor): I think scammer who is willing to wait 4 weeks still has considerable risks as 7 days delay + payment method delay of up to 6 days with SEPA adds considerable risks. Also if he waits 6 weeks he still has a 3-4 days delay. This protection is efficient in case the scammer does not want to wait. If he is willing to wait longer it does not make too much difference if he waits 6 weeks or 12 weeks. So extending that delay function for too long only adds usability costs but would not gain much security. That would be: So the delay would be after 28 days about 9 days. and only after 6 weeks be 0. |
|
I think that from all what is being discussed to deterr fiat scammers, payment delay is by no means the key measure. It is what makes meaningful the account age concept. But for determining a balanced delay in terms of security / usability I have a lot of doubts. I believe that having at least full 4-5 working days of delay is a huge deterrment for scammers compared to the current situation (0 delay). Adding more days is for sure more balanced towards security, but I am not sure if it is worth the loss of usability since maybe a delay of 5 working days imply a risk that most scammers are not willing to bear. That being said, no matter if the delay is 28, 15, or 5 days, a fading delay is a very good idea as IMO honest traders might feel it as gradual improvement, while scammers for sure will still feel it as annoying. |
|
Even Monero is our main revenue income I see the Fiat on ramp as the core mission of Bisq and the reason why it was started. |
|
Imo it was, and still is, a good reason why Bisq was started. |
|
I think the recent discussion on delays and deposits sounds good. I agree that a demo mode is good to have and probably needed for new users, but I do worry that it would be used for continued scamming, although it would be a really inefficient way. If all it good then all is good and if it doesn't work it'll have to be reconsidered. @HarryMacfinned In my opinion I see the fiat bridge as the core objective of Bisq. Others are doing crypto to crypto and I suspect it can be done in a more efficient way. It's basically a less interesting problem to solve. It's nice that the platform is flexible enough that it's so easy to just plug in anything, and it is currently providing the bulk of trading which is also nice. All that is for naught if there is no way to get in and out of fiat though. Maybe a time will come when there is no need for fiat but until then, Bisq is one of very few projects working against the complete eradication of privacy for Bitcoin users. |
|
@sqrrm wrote
Privacy providing is the main reason I joined Bisq (apart from lambos and chicks). You can look at the numbers for Bisq's best fiats : EUR and USD. Once more, this is not to suggest stopping fiat exchanging on Bisq. It's something which is absolutely necessary imo also. |
|
As implementation for the payout delay + decentralized reputation system will take considerable more time we decided to make quick solution based on the account age. See bisq-network/bisq#2801 While working on implemention of the payout delay I got more and more worried if it is feasible from a UX perspective. It turned out to have plenty of tricky edge cases which are also hard to communicate to the user. So I am getting worried if we are going in a wrong direction with it. Maybe the current much more simple approach of the above PR to limit new users to 0.01 BTC (fiat buyer only) and remove the restriction once the user gets attested by an already authorized user might make it much more simple? Need a bit of a break to it to get a fresh view. |
|
Ultimately, if implementation is a problem, maybe the delay process could be delegated manually at the discretion of the sellers. Although this would need to significantly extend the limit on number of days for all bank payment methods including instant methods (ideally, this extension could be limited only to the cases where the buyer is a fresh account) But don´t know if the above change would also be complex to implement. If you could briefly summarize those edge cases maybe we can come up with new ideas to simplify the process. |
|
It basically added an optional phase to the trade process (payout delay). We did not really want to add new optional trade period step but packing it into the last trade step is also not really correct. So all in all it makes the trade process much more cumbersome and complicate from an UX perspective. All is doable but I have the feeling that this approach might not be the best. As the delay will be a considerable drawback for both traders anyway it is questionable if they will trade much at all. I expect basically that optimal strategy for a new user:
So it might be that all that implementation effort is for a very small group of users who would either be in a hurry to buy BTC or who do not mind the waiting. But then they still need a counterparty who is willing to wait as well and do the extra work with the final release of the BTC and risking to lose his seller deposit in case he forgets. Costs:
The alternative approach would be:
So instead the extra protection with the delay we use the trade limit. As we want that anyway to allow users to try out Bisq (implemented with todays release), we might just skip the delay part at all. The small trade limit is much easier and we have that amount limit anyway - just with higher amounts (0.0625 BTC instead of 0.01 BTC - if BTC goes to 20K again thats anyway not so small)... So the users who would suffer from that alternative approach (compared to the delayed payout approach) would have that profile:
As said I am not sure how many users would fall into that profile. Security-wise we don't change to the delayed approach. |
|
Would it also be possible to limit the number of trades to one/day in the beginning without too much development effort? This would severely limit the damage a person with a stolen account could do. |
|
We do not have a tool to do that. The trade statistics do not contain any date which could be used to identify or verify a trader. So I think there is no way how we can do that atm. Would required to add new data but that will likely be problematic privacy-wise.... |
|
Ok, I see now the problem of trying to do the delay without changing the trading protocol. Regarding the alternative approach, we should be aware that if a new user wants to get attested doing a buy trade he will need to find a trusted user that is selling 0.01 BTC. Do you think there will be many authorized users that are selling such low amount? This could be solved doing a higher amount sell trade, but then the new user needs to own higher amounts of BTC (good for deterring scammers, bad for honest newbies). As general comment for both the delay approach and the alternative approach, isn´t it a bit risky that a scammer tries to attest his a account with a low amount sell trade? The victim might not notice or might not complain at all because of that incoming payment, and the scammer could get his account attested at a very low cost. |
|
If you guys agree that getting attested with a low sell trade is a risk, I suggest the following:
EDIT: If delays are not implemented and we are going to rely more heavily on the reputation system, then we should be very careful on how it is achieved the status of authorized user (the ones that are able to attest other users) so the attestation trust structure does not get compromised. So for example if above suggestion 2. is implemented, bronze users wouldn´t be able to attest other users even if they are more than 1 month old and do not have trading restrictions. |
|
There might be higher sell offer with small amount. We see similar at BSQ at. The better prices require higher amounts, smaller amounts have higher prices... Regarding the attestation of small amount sellers: |
Yeah, that was a general comment for both the delay approach and this new alternative approach. The attack I fear is that the scammer uses several stolen accounts with a very low balance and spends a little BTC on each one of them through sell trades. Those accounts get attested so then he can use those accounts to attest other stolen accounts with higher fiat balances by faking the payment confirmations.
But we are not sure if it was the limits what kept them out, or if it was low liquidity. In any case, IMO it is critical for the reputation system how users are going to achieve the status of being able to verify other users. So we can be confident that the reputation system is trustworthy enough. |
|
I think it depends on the amount on an account and the cost for the scammer to get access to it. The scammer had used about 14 accounts but only could cash out mainly 2 accounts (and 1 or 2 others with one tx). His gain was about 11 000 EUR in total. To be profitable he must not pay more than 1000 EUR per account (will prob. depend on the amount in the account). He lost also some Bitcoin in deposits once he was detected. He got detected after about 1-2 weeks so he needed to do it fast. Liquidity on Bisq was probably one natural protection as he probably could not cash out in 1 day all. Cashing out a lot very fast might trigger also bank-side protections as un-usual behaviour. They monitor clients spending behaviour and detect such things (I assume). So cashing out one account with many fast trades is very risky for him. The number of transactions is likely an important factor increasing his risk. So lets think through a potential scammers strategy to exploit our protection: Of course lots of uncertainties and unknowns in that model, but just trying to get a bit better an idea from his position. So it seems that the detection rate at banks is a main factor we need to consider. With that in mind restricting attestation to buy offers only would probably add substantial secruity. I think the first trade will be mainly a kind of "validation trade" where he starts to get attested. If the user buys or sells here a small amount is probably not that relevant, buying seems even more logical as new users might be Bitcoin newbies wanting to get in Bitcoin. |
As of one of the comments here from @sqrrm, the cost of a stolen acount is about 5% of the balance:
But let´s say the cost is 20% of the balance. If the balance of the cheap stolen accounts is just 50€, each account would cost just about 10€ (20 accounts would cost 200€). I think the scammer was succesful with more than 2 accounts, in several cases it was us who stopped him, not the banks. |
|
I realize that the scammer wouldn´t even need stolen accounts but just real bank account details (name and bank account number, no password needed) so the cost of setting up these accounts could be even zero and also no time pressure. So let´s say that the scammer sets up 3 accounts with real bank details (let´s call these accounts the scammer SEED accounts) and makes 3 sell trades of 0.01 BTC that would cost him 3*$60= $180. In the case we think possible that a scammer is willing to spend this money for this strategy, I doubt that receiving banks detect anything because those would be 3 completely different and unrelated transfers (the sender bank will notice nothing as it is just another outgoing transfer from a Bisq user). Only the seed account owners could detect the incoming money as suspicious, but would they take the time and effort to complain about receiving $60? But even if the seed account real owner honestly returns the money to the sender, whe have to rely on the Bisq user (BTC buyer) to report that he has got both the BTC and the money. Unless we require the Bisq buyer to be a trusted user, all these would be too much reliance on honesty, very specially considering that we are indeed dealing with a scam! Now after one month, the scammer does set up several stolen accounts with high balances, he attests those new accounts using the onions of the above 3 initial SEED accounts through fake fiat trades, so the fresh stolen accounts with high balances begin to age while remaining fully untouched. After 1 month he begins to cash out from those untouched high balance accounts as fast as he can. A variant of the above attack would be to use random valid generated account numbers with random names, expecting that transfer will be bounced by the receiving bank and the Bisq BTC buyer won´t report anything as he will get both the BTC and the money (only in the case we don´t require the Bisq buyer to be a trusted user in order to trigger account aging). A nasty variant of the above attack would be to harvest bank account data from Bisq users for the purpose of setting up the 3 initial SEED accounts. In this case the banks won´t notice anything for sure, only Bisq users could, and I guess active users would certainly notice, but maybe old or not very active Bisq users would not notice. Even if they notice we have to rely on them reporting they have received money for free. This variant would be nasty because once the scam is discovered honest bisq users would be indirectly involved on scammer trades, and it could damage the reputation system. So I tend to reassure myself that if the reputation system is going to become our main backstop instead of the delays, then becoming a verifier should not be easy / cheap.
I dare to strongly conclude that mantaining the account age at 0 while not having a real trade, that is, a buy trade with a trusted user, it is already a very significant security improvement as it really puts a lot more of time pressure on scammers than the current model where accounts begin to age without any trade at all. Small sell trades would also be real trades, but I am having many doubts about them as explained above. |
|
@mpolavieja Hope you don't find a similar problem with buy trades, otherwise we are back at zero ;-) |
Yeah, the worst attacks scenarios are the ones that we are unable to imagine. But anyway there is nothing we can do against those... I am trying as hard as I can with buy trades, but the thing with buy trades is that by definition it is a couple of orders of magnitude harder to get an account sending money than receiving it, and also with buy trades the right incentives are triggered to get the people we need to get into action (i.e. missing money in their accounts), on the opposite, selling trades by definition tend to trigger the wrong incentives on the people we rely on to discover the scammer. |
|
We still are based on the assumption that chargeback will happen and that it will happen in less then 30 days. Unfortunately we just got a new case which seems to be a scammer (not 100% confirmed yet) and he made trades 6 weeks back without any chargeback reported so far. One explaination could be that certain banks or Fintech companies like N26 might have it more difficult to start a chargeback (maybe they don't fulfill all banking requirements to be considered a first class bank). Or the scammer targeted victims where he knows that they do not check their accounts (e.g. they are old or in hospital,...) - might get a bit too paranoid... - but anyway, maybe we need to reconsider that above assumption as a weak one. Luckily the idea of @m52go with using a secondary account to make a small transfer and proof ownership of 2 accounts (can be any not only Paypal) might be a good alternative solution. It seems very unlikely that a scammer gets access to multiple accounts. And I assume it is likely that most Bisq users have at least 2 accounts. Though we cannot use that as mandatory protection as we cannot exclude users who have only one account.... |
How do we know he is a scammer then? As a general rule, if there are no chargebacks, then it is very difficult to know that a scam has happened. That doesn´t mean, of course, that we should take all measures we can against that. Using 2 accounts for verification it is defenetily a great idea! |
|
Because the receiver sent back and the bank bounced it abck because the account got blocked. Its a German female owner and the guy has very broken english. He stated himself to trade on behlaf of others (Btc club) but did never provide any proof of that not even a link. Has 2 disputes with 2 arbitrators and both report same behaviour and he used diff. accounts. He rejected all requests for proof (Pagesigner, video session). All his profile and behaviour is 100% scammers profile. So not 100% confirmed yet but 99% likely. |
|
@mpolavieja |
|
The reason I think the delay is a very important measure is because not only it deterrs scammers and makes account age much more meaningful, but also because it allows restoring damages to the seller and the scammer´s victim. That is, it helps respecting private property (although it might not restore the possible damage of the relationship between the seller and his bank). But yesterday @m52go came out with an even better idea (see #83) to address these same concerns as it even prevents all damages from happening instead of restoring them by not revealing the seller fiat account data unless the buyer is somehow trusted / verified. Maybe a bit more restrictive from UX pov, but excellent idea in any case. The relationship between fiat Bisq users and their banks is a very important asset for Bisq fiat liquidity, so preventing conflictive trades is very interesting. |
|
Yes, I think the 2FA idea is the best from cost/benefits persprective. If we findout it is not sufficient we still can add more like the delay or others. |
|
@mpolavieja Could you please close that? |
We can delay the payout of the BTC to the buyer in case his account age is less then 31 days.
This is only for Fiat trades to reduce risk for chargeback scammers.
Usually stolen bank accounts are detected rather fast and a chargeback happens in less than 4 weeks. Theoratically a changeback can be done even up to 6 months but we assume that is rather rare and a stolen bank account scammer will not know in advance how long it will take.
I suggest to delay the payout for all BTC buyers if their account age has lees than 31 days. The UI at the seller shows that the buyer has sent the Fiat. He will confirm that he has recieved it. If the account is too young he will get a popup with the information that the payout will be delayed by x days. He has to open the application after that period again to release the Bitcoin.
The buyer also gets the information displayed when he takes an offer and when he confirms payment sent.
In the offer book the account age of a BTC buyer is displayed and if a seller takes it he gets a popup displayed with the info that the trade will only be finalized after his account age reaches 31 days.
PS: Credit to the idea goes to Manuel!
The text was updated successfully, but these errors were encountered: