Delay payout for Fiat trades if buyers account is fresh

[ManfredKarrer]

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!

[mpolavieja]

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]

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]

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]

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]

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]

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: https://github.com/bisq-network/proposals/issues/23#issuecomment-482959414). 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]

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]

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]

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]

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]

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]

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]

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

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]

Btw. here is another older proposal which was intended against other scams (not stolen bank account scams): https://github.com/bisq-network/proposals/issues/27 Maybe there are some ideas which could become useful for our current problem as well?

[ghost]

@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 https://github.com/bisq-network/bisq/issues/2761 ) It could also help the transition with the possible future protocol.

[mpolavieja]

We were talking a lot about delays here https://github.com/bisq-network/proposals/issues/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]

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]

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]

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

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]

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

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

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

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

[ManfredKarrer]

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]

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.

[ManfredKarrer]

After a discussion with @mpolavieja we came up with those parameters:

Delayed payout based on account age only: New account: 4 weeks After 4 weeks: 1 week (forever, so even if the account age is 3 months there is a delay of 1 week) Transistion is linear

Buyers security deposit: New account: 30% of trade amount After 4 weeks: 10% of trade amount (forever, so even if the account age is 3 months there is a delay of 1 week) Transistion is linear

If trade amount is below 0.01 BTC (about 50 USD atm) there are no delays and increased security deposit (same as now).

Trade limits stay as they are: 1st month: 0.0625 (about 300 USD) 2nd month: 0.125 (about 600 USD) 1st month: 0.25 (about 1200 USD)

If the user makes a trade with a trader who has been signed (see #78) he will get removed his restrictions after 4 weeks and can also be a signer for other traders after that 4 weeks. So no delay and no extra high security deposit after 4 weeks of a completed fiat transfer in the trade.

There are 3 badges for trust level: Bronze, Silver, Gold

With the account age only (no signature) the user stays always with Bronze. If he got a signature from a trade after 4 weeks he gets Silver and after 8 weeks Gold (not so sure about that, though - maybe 12 weeks and more then one signature?).

Beside the Badge we show delay and security deposit as well as age of first signed trade as detail info in the badge. 2 icons for delay and signature should be added to the badge.

[flix1]

@ManfredKarrer please don't forget about the DEMO MODE for newbies. Don't impose delays on tiny (0.001 BTC) trades. It's the only way that new users have to test Bisq and discover how it works!

[ManfredKarrer]

If trade amount is below 0.01 BTC (about 50 USD atm) there are no delays and increased security deposit (same as now).

That is demo mode. So below 50 USD no change to current model..

[ManfredKarrer]

Update:

We need to remove the security deposit feature because when the seller creates an offer he does not know who will take it and what account age/signed state he will have. The security deposit is part of the offer payload and cannot be changed.

The alternative is to set by default a higher min buyer security deposit of 15%. That makes it easier also to users to understand the concept if we remove one dynamic element.

After a second thought about the 1 week delay after 1 months account age, I think 1 week is not enough as chargebacks are usually discovered only after 1-3 weeks. I also think that most users will try to get asap signed to get released the restrictions anyway so there will not be many users who only set up the account and then never traded, so not many users who would suffer from a longer delay. But if the delay is too short it is still a considerable secruity risk for a scammer who leaves his accounts without using it and then hopes to be able to cash out very fast. Specailly for payment methods which do have short trade period. I suggest 15 days as a better choice for the delay after 1 month.

[mpolavieja]

You mean that the security deposit will still be statically determined by the seller, like we are doing now, correct?

Regarding one month old accoutns that do not have a signed trade, I agree. In my view, an account that doesn´t have a "signed" trade should be treated similar to a zero days age account.

[ManfredKarrer]

The Securiyt deposit for the buyers is defined by the offer maker. The deposit for the seller is fixed. So yes the machinism is the same but instead of atm 5% min. deposit I would recommend 15% to reduce the risks for a scammer willing to wait 4 weeks and then hopes to can cash out faster as the the first chargebacks happen.

In my view, an account that doesn´t have a "signed" trade should be treated similar to a zero days age account.

So you mean we should keep 4 weeks delay forever if one has not trades with a traders who can sign him?

[mpolavieja]

So you mean we should keep 4 weeks delay forever if one has not trades with a traders who can sign him?

I meant that I for sure agree to raise it up to 2 weeks for unsigned accounts. Maintaining 4 weeks forever until trading with a trusted trader would make sense as well, as you said it would not harm users that are focused on validating their account and also it would keep everything simpler.

Only the DEMO users that have never traded with a trusted user would be negatively affected. But if a DEMO user has never traded with a trusted peer, we don´t know if all his buying trades are fake or not. Also, on the long term when we get to the point there are a lot of trusted / aged users, it would be unlikely (and a bit suspicious) that an active DEMO user has never traded with a trusted peer.

[ManfredKarrer]

I agree and tend to keep the 4 weeks so it make concept more simple as well to explain.

[justpaulgmx]

Fiat trading is Bisq's most precious feature and I'm excited it is getting the focus and protection it needs proactively. Thanks so much everyone!

[ghost]

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]

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.

[ghost]

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]

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.

[ghost]

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

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 https://github.com/bisq-network/bisq/pull/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]

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]

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]

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]

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

[mpolavieja]

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]

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]

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]

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.