Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delay payout for Fiat trades if buyers account is fresh #77

Open
ManfredKarrer opened this issue Apr 22, 2019 · 61 comments

Comments

Projects
None yet
10 participants
@ManfredKarrer
Copy link
Member

commented Apr 22, 2019

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

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!

ManfredKarrer added a commit to ManfredKarrer/bisq that referenced this issue Apr 22, 2019

Add min required buyers account age
Implements bisq-network/proposals#77

If fiat trade the buyer need to have an min required account age,
otherwise the payout will be delayed.
@mpolavieja

This comment has been minimized.

Copy link

commented Apr 22, 2019

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.

@mpolavieja

This comment has been minimized.

Copy link

commented Apr 22, 2019

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.

@psyantyst

This comment has been minimized.

Copy link

commented Apr 22, 2019

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.

@mpolavieja

This comment has been minimized.

Copy link

commented Apr 22, 2019

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.

@alexej996

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

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).
However this makes selling BTC harder not just for newer users, but older users as well, as everyone would have to wait a month before payout.

@mpolavieja

This comment has been minimized.

Copy link

commented Apr 22, 2019

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.

@psyantyst

This comment has been minimized.

Copy link

commented Apr 22, 2019

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.

@mpolavieja

This comment has been minimized.

Copy link

commented Apr 22, 2019

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.

@m52go

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

For more security it could be even required that the age remains frozen at 0 until X different payment confirmantions 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.

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.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented Apr 22, 2019

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.

@sqrrm

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

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.

@mpolavieja

This comment has been minimized.

Copy link

commented Apr 22, 2019

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.

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?

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented Apr 22, 2019

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

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented Apr 22, 2019

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.
To verify the witness you need to account data which is only exchanges with the trade peer. So at offer time one cannot verify but the taker will verify and if the maker was lying about it the trade fails.

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

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented Apr 22, 2019

Btw. here is another older proposal which was intended against other scams (not stolen bank account scams): #27
Maybe there are some ideas which could become useful for our current problem as well?

@HarryMacfinned

This comment has been minimized.

Copy link

commented Apr 23, 2019

@ManfredKarrer wrote

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.

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 )
It could also help the transition with the possible future protocol.

@mpolavieja

This comment has been minimized.

Copy link

commented Apr 24, 2019

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.

@flix1

This comment has been minimized.

Copy link
Member

commented Apr 24, 2019

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.

@mpolavieja

This comment has been minimized.

Copy link

commented Apr 24, 2019

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

  • Chargeback risk. I believe that chargeback does not describe the problem we are dealing here. The risk is that a fiat payment from a stolen account is reported. So IMO delay for young accounts should apply to any fiat payment subject to that risk (i.e. delay would not apply to face to face fiat payment)

  • IMO the minimum delay should ensure at least 2-4 working days have passed. That means 6-8 natural days as a minimum (to consider bank holidays chained with weekends)

  • Agree with the exception for low amounts. Great idea!

@sqrrm

This comment has been minimized.

Copy link
Member

commented Apr 24, 2019

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

@m52go

This comment has been minimized.

Copy link
Member

commented Apr 24, 2019

Chargeback risk. I believe that chargeback does not describe the problem we are dealing here. The risk is that a fiat payment from a stolen account is reported. So IMO delay for young accounts should apply to any fiat payment subject to that risk (i.e. delay would not apply to face to face fiat payment)

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

@mpolavieja

This comment has been minimized.

Copy link

commented Apr 24, 2019

@sqrrm

That kind of small scale trading could also be used as a way to verify accounts apart from users learning how the system works.

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:

  1. Adds a bit of complexity on the development (one more situation has to be handled)

  2. It has the (rather low) risk that the scammer tries to validate a stolen account hoping that the real account owner won´t notice or won´t bother to investigate a very small payment, and then after 30 days the scammer can begin to make higher payments without any delay with the stolen acount.

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.

@sqrrm

This comment has been minimized.

Copy link
Member

commented Apr 24, 2019

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

@mpolavieja

This comment has been minimized.

Copy link

commented Apr 24, 2019

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

@flix1

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

This old spreadsheet of payment methods might be useful:

BISQ TECH TREE 1. CURRENCIES, PAYMENT METHODS and LIQUIDITY
https://docs.google.com/spreadsheets/d/1CjYsaDT7WatSbbVFx7RJimLdMkoXhrYof3CGvDUektg/edit#gid=0

image

Anyone who wants is welcome to update it, add more risk paramenters, etc..

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented Apr 27, 2019

Proposed delay function from account age witness (no reputation factor):
Over first 4 weeks payout is delayed from 28 days (fresh account) to 7 days (account has 28 days).
Next 4 weeks delay goes from 7 days down to 0 days.

if(accountAge <= 28) {
	delay = 7 +  (28 - accountAge) / 28 * (28 - 7); // Linear function from 28 days to 7 days over 28 days period.
} else if(accountAge <= 56) {
	delay = (56 - accountAge) / 28 * 7; // Linear function from 7 days to 0 days over 28 days period starting at day 29. 
} else {
	delay = 0;
}

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.
Maybe we could even decrease it to linearely fade over 6 weeks to 0 days delay?

That would be:

delay = Math.max(0, (42 - accountAge) / 42 * 28);

So the delay would be after 28 days about 9 days. and only after 6 weeks be 0.

@mpolavieja

This comment has been minimized.

Copy link

commented Apr 28, 2019

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.

@justpaulgmx

This comment has been minimized.

Copy link

commented Apr 30, 2019

@HarryMacfinned

This comment has been minimized.

Copy link

commented May 1, 2019

Fiat trading was ~6% of trading on Bisq this month. While XMR trading was 91.5%.
And this is not a random number, but the trend for the last 6 months.
Offering fiat trading on Bisq is a lot of work for a tiny (and problematic) volume.
The ratios are really questionable imo.
I would replace precious with expensive.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented May 1, 2019

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.

@HarryMacfinned

This comment has been minimized.

Copy link

commented May 1, 2019

Imo it was, and still is, a good reason why Bisq was started.
But things have really changed, became harder, since 2014.
Building bridges between fiat world and crypto world is a 100% ok mission.
It's however a question of balance.
Monero is really making Bisq's daily bread since months (kindly unbeknownst to us)
All the brain time we use on trying to repair from our side the issues of the fiat system (and Bisq will be punished for that) would be much better used on crypto side.
Bisq does what he can to compensate the technical issues from the fiat side. But it's a Sisyphe challenge probably. I even won't be surprised that after the technical issues from this side, we'll nextly get also legal issues.
From the support side, it's quite clear that, as much as the crypto side is ok and ready to scale, it seems not really the case for the fiat side.

@sqrrm

This comment has been minimized.

Copy link
Member

commented May 1, 2019

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.

@HarryMacfinned

This comment has been minimized.

Copy link

commented May 2, 2019

@sqrrm wrote

Bisq is one of very few projects working against the complete eradication of privacy for Bitcoin users.

Privacy providing is the main reason I joined Bisq (apart from lambos and chicks).
The question is how this is the best and more efficiently achieved ? thru which channel(s) ?

You can look at the numbers for Bisq's best fiats : EUR and USD.
The graphics and the trends are not so nice. Given the rest of the context, I found rather doubtful that any future Bisq profitability will come from this side.

Once more, this is not to suggest stopping fiat exchanging on Bisq. It's something which is absolutely necessary imo also.
But, to expect volume and growth from the fiat side ? numbers from more than 2 years don't support this expectation.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented May 3, 2019

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.

@mpolavieja

This comment has been minimized.

Copy link

commented May 3, 2019

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.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented May 3, 2019

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.
One of the extra edge cases was how to handle the case when during the payout delay the buyers account get attested so that the delay could gets removed, but then the other peer need to know that as well. It could be known in advance (but not in all cases as SEPA has already 6 days + 30 days delay) but it would add more confustion to users why in certain circumstances the delay is not 30 days but shorter.... It also required a new message to be sent to the buyer once the seller confirmed receipt as that is the moment when the delay starts.
It required an extra tolerance time after the delay is over for releasing the btc. I would expect many disputes here as sellers might forget after 30 days and have less incentive (deposit). So 2 days seems the min. tolerance time here to avoid too many issues with disputes.

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:

  • Do a sell trade with an authorized user to get the attestation started (no wait time as buyer is unrestricted) or a 0.01 BTC buy trade.
  • Repeat above as often wanted.
  • Trade without restrictions after 30 days.

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.
Not sure if there are really so many users who are willing to do that (both sides). And if not we have put a lot of effort for little benefit.

Costs:

  • dev effort
  • added risk for bugs
  • added complexity will make any future change more difficult
  • higher risks for disputes if seller forgets.
  • bad user experience might lead to negative PR
  • higher prices of sellers might lead to negative PR ("Bisq is expensive")

The alternative approach would be:

  • New users are restricted to 0.01 BTC if they are buyer
  • Once they have traded with a authorized trader the 1 months waiting starts until they get attested.
  • After that they are unrestricted

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:

  • They dont care so much about the delay but want to buy quickly relative big amounts with few trades (they can also do multiple trades with the 0.01 BTC limit to buy bigger amounts).
  • They are willing to pay a considerable higher price as sellers who are accepting such newbies will take higher risk for losing their security deposit as well have the added inconvenience of the delay.

As said I am not sure how many users would fall into that profile.

Security-wise we don't change to the delayed approach.
The "demo" mode with 0.01 BTC trades and no delay was part of the proposal anyway. I don't consider that a critical risk as well we can lower that amount if we would see that it gets abused.

@meapistol

This comment has been minimized.

Copy link

commented May 4, 2019

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.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented May 4, 2019

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

@ManfredKarrer ManfredKarrer referenced this issue May 4, 2019

Closed

Cycle 1 #271

@mpolavieja

This comment has been minimized.

Copy link

commented May 4, 2019

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.

@mpolavieja

This comment has been minimized.

Copy link

commented May 4, 2019

If you guys agree that getting attested with a low sell trade is a risk, I suggest the following:

  1. Not allowing low sell trades to be used for attestation (too harsh?)
  2. Allowing low sell trades to be used for relieving trading restrictions after 1 month, but the badge would remain at bronze until a buy trade (higher than X?) with an authorised user has been done.

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.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented May 4, 2019

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:
It would have been the same in the previous concept. I agree there is some risk but it is hard to say if it is a realistic risk the scammer could abuse. Note that the normal trade limits are still in place (1st month 0.0625 BTC, second 0.125, after 0.25) which is still rellative low and kept scammers out for 3 years. We can also increase min. trade amount (0.0001 btc) so that the min amount he trades is not too small to stay unnoticed.
To use it only for buyer might be a bit too restrictive but maybe its required to increase security here....

@mpolavieja

This comment has been minimized.

Copy link

commented May 4, 2019

It would have been the same in the previous concept

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.

Note that the normal trade limits are still in place (1st month 0.0625 BTC, second 0.125, after 0.25) which is still rellative low and kept scammers out for 3 year

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.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented May 4, 2019

I think it depends on the amount on an account and the cost for the scammer to get access to it.
There is some risk that the victim or bank detects it even with small amounts. Of course we don't know number but from what we have learned in the past weeks we could try an educated guess.

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:
Lets say he got 20 cheap accounts with costs about 200 EUR (total cost 4000).
He starts with small sell trades to get attested with all. He need to wait one months and then can cash out 0.125 BTC per tx (about 600 EUR). If he suceeds he has gained at least 400 EUR (600-200). So if he has 50% sucess rate that the sell trade kept undetected he would be break even.

Of course lots of uncertainties and unknowns in that model, but just trying to get a bit better an idea from his position.
We saw that with his 14 accounts he was only successful with 2, so detection rate at banks seems ratehr high. Of course receiving money might be less easily detected as spending. Specially spending small amounts I think is monitored well as there might be scam schemes where they try to make many micro transactions in the hope the victims don't notice it.

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.

@mpolavieja

This comment has been minimized.

Copy link

commented May 4, 2019

Lets say he got 20 cheap accounts with costs about 200 EUR (total cost 4000).

As of one of the comments here from @sqrrm, the cost of a stolen acount is about 5% of the balance:

From what I've seen on darknet markets it seems stolen accounts go for 2-5% of the account 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.

@mpolavieja

This comment has been minimized.

Copy link

commented May 4, 2019

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.

@ManfredKarrer

I think the first trade will be mainly a kind of "validation trade" where he starts to get attested.

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.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented May 4, 2019

@mpolavieja
Good analysis and finding! Yes that makes the attestation for sell trades too dangerous.

Hope you don't find a similar problem with buy trades, otherwise we are back at zero ;-)

@mpolavieja

This comment has been minimized.

Copy link

commented May 5, 2019

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.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented May 5, 2019

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

@mpolavieja

This comment has been minimized.

Copy link

commented May 5, 2019

he made trades 6 weeks back without any chargeback reported so far.

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!

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented May 5, 2019

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.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented May 9, 2019

@mpolavieja
Maybe there is still a way to add the payout delay without big effort:
To use the timelock function on the tx level again (as it was in earlier trade protocol) but to make it more simple so that it does not require an extra handshake cycle. It still would be a kind of hard fork but maybe we find some way to mitigate that to cause less harm.
Idea is to just add the timelock in case the buyer is considered risky. Based on the risk level the timelck can be defined from 0 blocks to 4300 blocks (about 1 month). It can be determined at take offer time and without haveing thought in depth about it I do not see a big problem in implementing that. Usability would be the same, just require an info that the btc are released but not usable until the timelock is over. Hope it would not turn out as well in too much UX confusion when looking deeper....

@mpolavieja

This comment has been minimized.

Copy link

commented May 9, 2019

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.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented May 9, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.