Proposal to increase trade deposit to 30%

[sqrrm]

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

Due to the amount of cases reaching the arbitrator (about 1 per day) I have made a PR to increase the deposit to 30% to incentivize following the trade protocol, as can be seen in https://github.com/bisq-network/bisq/pull/4330

I realize that this is a crude tool that's not helping usability. That has to be weighed against the cost of too many non bug trades not getting resolved before going to arbitration.

[wiz]

Thanks for proposing this. A few thoughts:

1) Why do you feel that having 1 case per day going into arbitration is excessive? Trades can go into arbitration for many simple reasons, such as the maker simply not noticing their trade offer has been accepted, so shouldn't we work on adding native OS notifications or other methods to push traders to complete trades using the trade protocol?

2) Locking up more Bitcoin for use in security deposits reduces the amount of Bitcoin that users can use to make offers, so I'd expect this will reduce the amount of trade offers on Bisq - can @bisq-network/growth team predict approximately how much this will reduce Bisq offers?

3) Requiring more Bitcoin for use in security deposits increasing friction to take offers, so I'd expect this will reduce the amount of trade volume on Bisq - can @bisq-network/growth team run some numbers to predict approximately how much this will reduce Bisq volume?

4) A few months ago, the minimum security deposit requirement was increased from 6% to 15% - how did this affect the number of arbitration cases, and how did this affect Bisq trade volume? can @bisq-network/growth team run some numbers to analyze the before and after effects of the 6% to 15% increase?

5) How did you arrive at the 30% number, and how much do you predict this will affect the number of arbitration cases per day? If the 30% increase is not sufficient to reduce the number of arbitration cases to what you feel is acceptable, do you think we plan to again propose to increase a third time?

Regardless of all of the above, isn't having an efficient arbitration process that traders can use a necessary requirement for any decentralized P2P trading network? What if the the actual problem isn't that the security deposits are too low, but that the arbitration system itself should be improved so that 1 case per day is not "excessive" ?

[sqrrm]

The trade protocol we have is built to have a very low number of arbitration cases. For now we're surviving by the fact that we have an arbitrator that handles these cases. There is a rather high probability that the arbitrator will leave.

Once there is no arbitrator each user would have to go to the DAO to ask for reimbursement for each case that goes to arbitration as the DAO is the ultimate arbitrator. That leads to users not getting their funds back for a month or two, a pretty bad situation for both users and DAO contributors alike.

The jump from 15% to 30% is meant to be a significant increase. If the extra incentive doesn't help we can lower it.

I think we should have notifications, that would be great. I think the api can help with that, but that's not ready for production.

[MwithM]

Before taking this decision, we need to have a deeper understanding about why trades get into arbitration: Are sellers or buyers causing more arbitration cases? Low amounts have more cases? What about fiat vs altcoins? Also, what happens once the trades get to mediation? Will the refund agent always give 30% of the trade funds to the victim of an unresponsive trader? What if the protocol violator claims that he just forgot, or has a bug and is not cooperating with mediators?

Before increasing the security deposit, we should enforce sellers to follow the protocol. Now they can get through a protocol violation without any penalty. https://github.com/bisq-network/proposals/issues/224#issuecomment-645024054

I'm only willing to use a higher deposit than the default for face to face transactions. I don't see why Bisq should impose something that I, and advanced user, don't feel necessary.

[RefundAgent]

Virtually all cases that go to the Refund Agent are because one of the traders abandons the trade. The number of abandoned trades is higher when the market is volatile and most of the cases can be suspected to be future trades. That is, the price moved against the buyer who simply leaves. There are also cases where the seller don't release the btc, probably because he/she does not care enough about the security deposit.

Increasing the security deposit will give both buyer and seller more skin in the game, they will do much more to overcome any difficulty in paying, they will have incentives to speed up the trade and they will be less inclined to "forget" the trade. They will be more secure that the other trader will honour the contract and do so quickly.

If a 30% security deposit is a suitable amount is unclear but it should be tried to see how traders react. Better would be a security deposit which reflects the price of the option that an offer in reality is. I. e. the past volatility could be used to estimate the correct price of the option. The DAO must realise that an offer is an option and trying to force traders to fulfill their obligations using other means (reputation, blacklisting by "trusted" team members, ...) will be a very cludgy method indeed, probably with plenty of not intended consequences.

As it is now the Refund Agent follows the mediators suggestion since in essentially all cases one trader does not respond. Even if both traders do respond there is never anything to change. There are no known cases where the mediators have made any mistake.

Bisq should not need any mediation at all. Bisq is a platform where traders meet and make their trade, secured by the security deposit. Mediation and refunding should only be used in those rare cases where there is a bug in Bisq.

As it is now I doubt that the DAO will find anyone to replace the Refund Agent. The Refund Agent is a single point of failure which goes against the philosophy of Bisq.

[flix1]

I agree that the security deposit is the most important feature securing trades and we should do much more with it.

HOWEVER it is also the biggest barrier to entry in Bisq and I'm certain it is what turns away most newbies. Consider the learning curve!

I would really NOT make a high security deposit a default, forced feature. It should be as voluntary and customizable as possible.

One thing that we could do is make the % of the security deposit much more visible in the order book and and warn accordingly. Also allow users to filter by security deposit %. Between the Payment method and Time since signing columns there should be a Security Deposit column. If it's an important feature, let's make it prominently visible for everyone!

The philosophy is to give users tools, not to force them onto a path.

[wiz]

Well of course having a TTP / CPOF for Arbitration goes against the spirit of Bisq, nobody is going to disagree with this statement, and I agree it’s an obvious security hole. But this proposal doesn’t acknowledge or address the real issue.

The elephant in the room that nobody wants to talk about, is that when the Bisq v1.2 trade protocol update removed the 2 of 3 multisig Arbitration system to eliminate the TTP, it neglected to provide a replacement Arbitration system, despite the need for Arbitration remaining present in the trade protocol.

So now Bisq is in the awkward situation where Bisq traders still need an Arbitration system and due to the lack of one they are not happy. This is very obvious in hindsight and I deal with it every day as a Mediator. I understand that our Growth team has hard data showing the XMR trading volume declined sharply immediately after the v1.2 update.

This proposal to raise the security deposits only serves to lockup more trading capital, introducing more friction and makes users less happy, driving them away further. It didn’t work last time and it won’t work this time. We will only lose more and more users and trading volume.

Instead of another band-aid, can we please address the real issue here and discuss how to best implement a properly decentralized and secure Arbitration system to give the users what they really want? Until the need for Arbitration is completely removed, which seems nearly impossible to do, Bisq still needs an Arbitration system. If you raise security deposits higher and higher you are only removing the need for Arbitration because no users will be trading on Bisq anymore.

In the past I have proposed implementing a new Arbitration system by utilizing multiple different pre-signed timelocked payout transactions that are encrypted to mediators or arbitrators, so they can decrypt and publish the one they feel is best. While my idea is still raw and needs additional discussion to resolve the remaining issues, I feel it has merit and would address the core issue Bisq is now facing.

So with all due respect I feel I need to NACK this proposal and I again ask the dev team to try harder to address the core issue here - please come up with a proposal for the new decentralized Arbitration system that was painfully missing from the v1.2 update last year.

[flix1]

In the past I have proposed implementing a new Arbitration system by utilizing multiple different pre-signed timelocked payout transactions that are encrypted to mediators or arbitrators, so they can decrypt and publish the one they feel is best.

@wiz This would definitely be a superior model to the refund agent, especially if voluntary. But I would consider operating Bisq on a sort of "freemium" model where the basic platform without arbitration, mediation or refund agent is totally free to use but you can sign up to extra services (mediation, arbitration, etc) by paying a fee. This would make the cost of those services very clear.

Arbitration has a cost. Any trade that reaches arbitration/refund agent should be heavily penalized. Not just the guilty party, both parties should suffer some cost. That is the only way to make sure that people make an effort in avoiding it.

I don't see how arbitration will ever scale 'though, unless it is 1/1000 trades. I don't see Bisq having millions of users and hundreds of arbitrators.

The trade protocol we have is built to have a very low number of arbitration cases. For now we're surviving by the fact that we have an arbitrator that handles these cases. There is a rather high probability that the arbitrator will leave

@sqrrm if we are having these problems keeping 1 arbitrator. Can you imagine what it would be like with dozens? hundreds?

[wiz]

Please don't confuse the removal of the need for an Arbitration system with the removal the Arbitration system, like the v1.2 update did. If you remove the system before you remove the need for the system, you just piss off the users. And even when you get the need for Arbitration down to 1 case for every 1000 trades, you still need an Arbitration system, so you can never remove the Arbitration system.

[flix1]

And even when you get the need for Arbitration down to 1 case for every 1000 trades, you still need an Arbitration system, so you can never remove the Arbitration system.

No?

You could conceivably have a 2-of-2 multisig Bisq with no arbitration.

Fill or kill. Either the trade is completed or the funds are timelocked for 100 days and return to original addresses.

Consider the possibility. With a high (voluntary!) security deposit it could work well. It would be scalable and require no human interaction whatsoever.

[wiz]

Either the trade is completed or the funds are timelocked for 100 days and return to original addresses.

Okay, I'll sell you Bitcoin, wire the money to my bank account 1234567. Then after I get your bank wire I just wait 100 days and I get my Bitcoin back. Since there is no Arbitration you have no way to prevent this.

[flix1]

Okay, I'll sell you Bitcoin, wire the money to my bank account 1234567. Then after I get your bank wire I just wait 100 days and I get my Bitcoin back. Since there is no Arbitration you have no way to prevent this.

You are right.

Then Mutually Assured Destruction: Either trade is completed or funds are locked up forever until it is.

[wiz]

Then Mutually Assured Destruction: Either trade is completed or funds are burned.

Okay, now that I got your bank wire. I'll only sign my key for the 2 of 2 multisig for a payout TX that pays 50% to me and 50% to you, this is also known as a ransom attack. Since you'd rather get 50% than 0% you would have no choice to accept it.

[flix1]

@wiz you are making a very good case for arbitrators.

Why not have them be a voluntary feature with a fee? If they provide so much value compared to a no-arbitration system... most users will happily click on the "pick arbitrator" option.

Or even have the arbitration system be independent from Bisq. Users can still sign transactions affecting the funds locked in multisig after the fact...

[wiz]

The problem with using a 2 of 3 system for Arbitration is that the Arbitrators can steal all Bisq trade capital because they can just take all offers and then they have 2 of 3 keys. My proposal to keep the 2 of 2 model but have both parties create pre-signed timelocked payout TX for various scenarios, and encrypt these payout TXs to a group of trusted people who would all have to collude together to steal the funds, is also vulnerable to this attack, but using SSSS it would require several people to collude together which distributes the risk enough to make it much harder to do the attack. The risk can never be eliminated, so the only thing we can do is spread out the risk to more people and slow things down with timelocks.

[flix1]

My proposal to keep the 2 of 2 model but have both parties create pre-signed timelocked payout TX for various scenarios

You have convinced me that this is the best solution.

and encrypt these payout TXs to a group of trusted people

This is the part I have a problem with. If we could remove the trusted people from the equation and have some rule-based mechanism or automatic system doing this part...

[wiz]

No, you can never remove trusted people from the equation, especially for fiat trades. You can only spread the trust around to more people, and slow down their action with timelocks.

When one party says they sent the funds and one party says they didn't receive the funds, someone needs to examine the evidence and make a judgement call about who they think is the fraudster. There is no way to automate this.

[flix1]

Then those trusted third parties have to be:

1. Independent from Bisq
2. Paid
3. Have reputation / be policed

...and if Bisq is to scale to millions of users there will have to be 100s of them.

[wiz]

I feel we're getting a bit off topic, the core issue that should be discussed in this proposal is that the v1.2 trade protocol has many obvious flaws, and this proposal attempts to band-aid over them. Here's another example of a major flaw in v1.2 trade protocol: https://github.com/bisq-network/bisq/issues/4162

This proposal would put a very heavy burden directly onto users as an attempt to solve the shortcomings of the v1.2 trade protocol, which will not work and only drive users away. We need to talk about the v1.2 trade protocol flaws and how to fix them.

[flix1]

Sorry if it's off-topic, but for me the Trusted Third Parties discussion is the most important one for Bisq. If there is no way of trading without them it... well it removes one of the biggest reasons for Bisq. The moment you have TTPs you are open to censorship since it would be easy to shut down Bisq by going after 10s or even 100s of arbitrators. If you are going to have to trust the platform you might as well go to localbitcoins or hodlhodl or another P2P market that is not a DEX.

Atomic swaps or similar would remove this problem for any Bitcoin-based altcoin (including BSQ).

An open source automated check on payment could work for other altcoins (eg: Monero) while still removing the need for TTP. If it's on a blockchain there should be a way to verify payment programatically.

Fiat payments will always be the hardest problem to solve, hence the most important. There has to be a way...

Of course the moment you get fiat on a blockchain (govt- or bank- backed stablecoins) you can use to atomic swaps...

[flix1]

Fiat payments will always be the hardest problem to solve, hence the most important. There has to be a way...

There once was a project called Coinffeine that used payment channels to "stream" funds by doing consecutive micropayments while reusing a small security deposit in Bitcoin that was 100% of each micropayment. So that each micro-trade was fully backed but still you could never lose more than a small amount if something went wrong. It required an instant-payment API-enabled payment processor. It worked, although the project never took off.

But now that Lightning Network has advanced a lot, there might be a way to combine it with a Revolut, CashApp, Venmo style app to do something similar..

[wiz]

Bisq should not need any mediation at all. Bisq is a platform where traders meet and make their trade, secured by the security deposit.

The key word in your statement is "should" - you describe a beautiful vision of what Bisq can aspire to become someday. If Bisq actually achieves a near-zero rate of Arbitration cases, then we could discuss removing the Arbitration system, and doing so wouldn't upset users and trading volume wouldn't drop. However, it's precisely because Bisq removed the Arbitration before removing the need for Arbitration that Bisq users are unhappy and trading volume has dropped. So while everyone will likely agree that Bisq "should not need" mediation or arbitration, it still does.

Mediation and refunding should only be used in those rare cases where there is a bug in Bisq.

Again, that would "should" appearing. Again, this is a great goal. But in reality, every day we see Bisq users make mistakes, users forget about trades, users aren't properly notified on trade events, we still have the occasional scam or fraud attempt, etc. etc. - so until Bisq is absolutely perfect Bisq will still need support agents, mediators, arbitrators, etc. for the community, and if Bisq does not provide that users will go elsewhere. Increasing security deposits only drives users away.

[flix1]

@wiz what do you think about making arbitration optional (and charge a fee for it)?

If it is that important then most users would choose it... and those that don't would know the risk they face without it.

Also it would allow us to gauge demand for it, play around with the fees and eventually make it self-sustaining since it would be easy to recruit more arbitrators knowing how much they get paid. It would put a clear value on it. In fact the arbitrator should decide how much to charge.

Since you only need to provide the pre-signed txs to the arbitrator... there's no need to change the 2-of-2 multisig protocol. It would not require any changes to Bisq protocol. It could even happen outside Bisq. Being an external service it would not pose a censorship threat.

[flix1]

Virtually all cases that go to the Refund Agent are because one of the traders abandons the trade. The number of abandoned trades is higher when the market is volatile and most of the cases can be suspected to be future trades. That is, the price moved against the buyer who simply leaves.

@RefundAgent

Do these ever happen with faster payment methods ( <24h trade time)?

[freimair]

Fiat payments will always be the hardest problem to solve, hence the most important. There has to be a way...

isn't that why we have notary trust accounts (please forgive if I got the translation wrong) in the real world?

could we do something like this? just food for thought, though...

[sqrrm]

It seems the discussion here has veered off topic. The question is if we should increase the trade deposit to 30%. If we don't it seems the refund agent will leave and a much worse user experience when trades go to the arbitrator-less arbitration.

This is not a proposal to ignore the issues with the trade protocol, it's a proposal to keep us going while we find better solutions.

[MwithM]

The question is if we should increase the trade deposit to 30%

Not without making sellers accountable first, and not without running some numbers to evaluate the impact. What % of total trades are going to arbitration? Maybe the trades going to arbitration aren't reduced just because there are more daily trades at Bisq, but the overall % is decreasing as the platform improves and people learns.

If it's about giving refund agents incentives to stay, I'd rather just raise the min security deposits to 20% and charge 2-5% (or a fixed fiat rate, like 10-50 USD) as arbitration costs. Those who follow the trading protocol should not suffer the costs of those who don't.

[flix1]

@sqrrm

Regarding only the topic of this proposal:

It's not the first time that a security measure is put in place for everything, even payment methods or currencies that have never had an issue.

If instant payment methods never have a problem with "future trades" then any increase in the security deposit should not affect them.

I would like to recall a concept we used to have in the past and has now been almost forgotten: the demo experience. For small trades (0.01 BTC) or trades in markets with zero activity we should have fewer hurdles and as little friction as possible. I even recall the discussion on having 0% security deposit for small JPY/BTC trades when trying to kickstart that market.

What is the point of having a 15% security deposit for ARS/BTC when there hasn't been a trade in that market in 9 months? Why would you need a 30% compulsary security deposit for GBP/BTC via UK Faster Payments if there has never been fraud in that market?

If there is one area in which Bisq is still awful compared to anything we might consider competition it's the onboarding experience and first trades ever for a new user.

Please let us have some broken down data so that we only increase security where needed.

[clearwater-trust]

Bisq is a DEX because it cannot require KYC- NOT because it lacks trusted third parties. The developers are trusted third parties. Everyone that holds a bond is a trusted third party. Fiat trading must include a trusted third party. I don't know if that's in the form of a refund agent, arbitrator, bozo the clown... or whatever. But you MUST provide a trusted third party to fiat traders or this project is doomed.

And really the opportunity to make MONEY in this market is going to be enormous. We want BSQ to INCREASE in value. Think like a business- Not a crypto nerd.

Don't think of them as arbitrators- think of them as developers with arbitration roles.

[Conza88]

Why does the security deposit have to be set?!

There should be a market for it.

Maybe keep the minimum, but really - I would have NO problem doing a 100% security deposit. Having made that as an offer to BUY BTC, the BTC seller would be more likely to take my trade, knowing they're secure in the trade being done?

As opposed to someone with 15% security deposit.

[ricardosaurio]

I belive this to be a no brainer. If I could use more than 50% i would.... at least for my country. If im offering a 50% security deposit, the other trader would feel safer too.

[m52go]

It seems there's general agreement that the protocol itself needs to be revisited, but since that is not the topic of this proposal, I will refrain from commenting on it here. But I hope it gets more attention soon.

As mentioned above, the rational result of doubling deposit is a drop in liquidity...if it takes twice as much capital to make an offer, people will make fewer offers. We've already seen how the potential to tie capital for 10+ days has killed the XMR market—the key to DAO profitability. The more capital you require upfront and the longer you tie that capital up, the more you discourage trading.

With that said, we have to make the best of the situation we're in. It's probably not realistic to expect an improvement in the core trade protocol in the near-future, and the situation with the refund agent requires urgency.

To that end I'll second flix1's suggestion to make such an increase voluntary, and to make it more obvious in the interface. I actually suggested this over 2 months ago in a Keybase chat upon finding out that many users don't realize that configuring security deposit % for buyers is possible right now (related tweet from the time).

If deposits are going to be raised, these are the criteria (in my opinion):

• voluntary
• with clear messaging in program (offer book, make-offer screen, tool-tips, wiki links, etc)
  • make benefits clear
  • signal it's a test/temporary
  • user can choose lower deposit if they want
• applied to markets/trades which need it most (based on analysis of dispute cases)...is there a Pareto scenario here?

Otherwise we take a big risk with liquidity, trading activity, and furthering Bisq's reputation as a mechanism that is ever-unfriendlier to active traders...all of which we really cannot do right now.

I'm only in favor of this move if the criteria above are met and if the move is used as a stepping stone for implementing a refined/improved trade protocol as quickly as possible (i.e., top project priority).

[wiz]

I agree with @m52go that if some users want to voluntarily increase the security deposit to avoid arbitration, Bisq should support and encourage this, with better indications of the required security deposit (such as a new column in offers tables), popup or other educational material to educate about how to better utilize security deposits, etc. and only encourage it on the markets that have excessive arbitration, for example JPY market can even lower the security deposit.

[RefundAgent]

An offer on Bisq is an option and needs to be treated as such. Ignoring this fact will simply destroy Bisq since there will be no sellers (who will lose money) if the security deposit is too low compared with the correct “price” of the option. Instant trades are no exception but are cheaper since the option is short. It may well be that the low trading activity on Bisq is because the default security deposit is too low.

Having the security deposit cleanly visible in the offer book might work since sellers that take or offer too cheap options will learn the hard way what an option is. Traders that want extra assurance that the contract will be honoured can then offer or take high security-deposit offers. Traders that accept the risk of default of the payer can take the cheap options and “save” money. The market will quickly find out the correct security deposit.

The present default security deposit is too low in volatile times and might kill Bisq.

[m52go]

It may well be that the low trading activity on Bisq is because the default security deposit is too low.

I've never encountered this sentiment anywhere. If it is correct, I would prefer to see it proven in 1 market first before forcibly applying across all markets. Otherwise make it voluntary.

The market will quickly find out the correct security deposit.

Exactly.

[sqrrm]

Forcing the minimum deposit to 30% seems rather contentious which I can understand. Force is bad, let's encourage better use of deposits by traders.

I implemented the increased visibility of the deposit for a trade, like @flix1 suggested, this is not really proposal material but I mention it

I also suggest to set the suggested deposit to double the price range over the trade duration, looking backwards. Example: USD trade with a delayed tx timeout of 20 days. The trade range for the last 20 days is about USD8800-10000, conservatively a max drop of 12%, which gives a suggested deposit of 24%. This can still be changed within the current range.

I also think the deposit should be symmetric, so instead of setting only the buyer deposit when creating an offer the deposit should be what each trader has to put down.

[wiz]

@sqrrm Thanks a lot for implementing the community feedback from this proposal discussion. I really like the deposit being a column on the offers table, maybe also add (XX%) after the amount?

As for the "suggested" deposit I agree it should be suggested by an algorithm but it probably shouldn't use trade statistics data for obvious reasons. Since the risks are often related to payment method risks, how about starting with a hard-coded mapping of payment methods to % suggested deposit? For example, Japan Bank Transfer should be lowest, but Zelle should be medium, etc. based on their "risk" level.

[sqrrm]

The risk is mainly related to the duration of the trade, the method of payment. If the trade duration for Japan Bank Transfer is shorter then it would have a lower suggested deposit naturally.

I think using trade statistics is fine since it's just a suggested value.

[wiz]

Just make a simple algorithm that uses the 2 values from each payment method: https://github.com/bisq-network/bisq/blob/master/core/src/main/java/bisq/core/payment/payload/PaymentMethod.java#L146

1) trade time duration (X days) 2) payment method risk level (very low, low, mid, high, very high)

[clearwater-trust]

YOU CANNOT CODE YOUR WAY OUT OF THIS PROBLEM. Begin discussion on protocol improvement.

[wiz]

@clearwater-trust keep in mind this proposal is about how to improve the security deposit system - we can discuss how to improve the trade protocol in new proposals

[m52go]

Simpler deposit % algorithm might be better (flat or tiered), but that's not a strong opinion. Symmetric deposits are great!

Most important, I think, is to display deposit % instead of (or in addition to) BTC amount in the new Deposit column.

[RefundAgent]

Great proposal which will give a clear indication of the default-risk involved with a particular trade. In case the suggested deposit is "wrong" the market will correct it. I also think that the %-value should be given. And the security deposit should be symmetric.

[clearwater-trust]

If my trade goes to the DAO or @RefundAgent for "arbitration" and I don't get ALL of my "security" deposit back after the BUYER bails out of the trade... I swear to god I'll have my vengeance on you. :1234:

[eigentsmis]

+1 for the symmetric security deposits!

[eigentsmis]

If my trade goes to the DAO or @RefundAgent for "arbitration" and I don't get ALL of my "security" deposit back after the BUYER bails out of the trade... I swear to god I'll have my vengeance on you. 🔢

The arbitrator should be able to decide who the party who bailed the trade was and penalize that party with 100% of the security deposit, be it the seller OR the buyer.

[chimp1984]

A few comments:

• Yes the option character is important to take into account. See also Bitmex blog post about Bisq: https://blog.bitmex.com/atomic-swaps-and-distributed-exchanges-the-inadvertent-call-option/ "Although it may make marketing the platform more challenging, it might make Bisq more robust to rebrand these trades as options and encourage sellers of Bitcoin to set the deposit price such that it’s consistent with the premium payment for the equivalent option based on the price volatility of the assets involved"

This is a scaling limitation as well. If Bisq grows more ppl will discover how to benefit from those options. Make a trade if price move is larger then deposit take loss of deposit into account. It's economically rational to act like that. So it is really important that we see this problem as a different class of problem than UX problems, bugs, trader being lazy or careless,...

• Any refund agent case causes cost/risk for the refund agent not only for the trader. Giving the trader the option to set the deposit might not solve our problem if the trader does not care so much about the delay (or more likely that he does not understand the full context).

• The buyer is the one who can "cancel" the trade. So I don't see the need to increase the sellers deposit as well. Though we could increase the min. deposit for sellers so for small amount trades where the seller just don't care to confirm get covered as well.

• We should consider the trade off between complexity and cost of locked up funds. Using a more sophisticated model (as we used for the fees in the past) makes it difficult to understand for users but could optimize the amount of the required deposit. Maybe it would be a good start to do a more detailed analysis of the refund agent cases of the past 3 months to see which payment methods, trade amounts, trader role (buyer/seller) are causing the majority of cases. I assume its 80-90% high amount trades (XMR) with buyer doing a future trade. So maybe it would be even enough to limit the increase to buyers on XMR markets with amounts > 0.1 BTC? If we have the data we could also justify it by showing that this market segment caused most problems.

• We should consider the "cancel trade" feature. It might be a relative easy solution for a "clean" way to step out.

• If a more sophisticates solution takes longer, lets make a quick change to solve the refund agent problem. The refund agent could revoke any day and then Bisq has a much bigger problem if each day 1-2 cases go to the DAO for reimbursement. It also would require some software changes (to get arbitration cases closed, to provide a proof for the DAO).

• The alternative for deposit would be some sort of reputation. For Fiat we could use the account witness feature as a payment account is a "scarce resource" and once it got flagged it will cause disadvantage for the trader. But of course thats a big minefield with many hard problems (decentralised reputation). Se better not count on that soon.

So as conclusion I really would suggest to make first an analysis of the data and try to find out which trades cause 90% of cases. Then implement an aggressive solution to bring those cases down to 1%. If that is achieved we can fine tune and even if refund agent revokes there are not that many cases for DAO reimbursement to cause a major problem.

As said my bet is 90% are XMR trades over 0.1 BTC and buyer is not paying. @RefundAgent : What is your guess? Or can you provide data?

[wiz]

@chimp1984 Thanks for joining this discussion, you have a lot of good points.

I like your suggestion to add a "cancel trade" button! As a mediator, I feel this would reduce the majority of cases, as users would be able to resolve it themselves. However, to financially incentivize the buyer to actually press the button, they would need to be able to recover some of their deposit back, which I feel should should start at 50% and go down to 0% over time until the timelock expires and arbitration is possible. It can be calculated in realtime and displayed as an option to the buyer.

I also like your suggestion to introduce some reputation into the mix. What do you think of my previous proposal? https://github.com/bisq-network/proposals/issues/138

[flix1]

@wiz it's very hard to do user reputation. However it should be relatively easy to do payment account reputation now that we have account signing, etc...

[RefundAgent]

A "cancel trade" button will make the option more exotic but not change anything fundamental. The buyer will then get some refund if he defaults (uses the "cancel trade" button) which makes the option cheaper for the buyer. This needs to be compensated by a higher security deposit. Payment account reputation is separate from the issue of correctly pricing the options.

I made some statistics of the last 28 trades dating back to May 20:

8 buyer unresponsive or quit 5 buyer claims problems and does not pay 8 seller does not confirm or respond. 3 seller confirms in chat. 1 genuine bank trouble. 1 late payment 1 genuine bug 1 seller gave incorrect bank info. no trade occurred.

Three of these trades have been xmr with a trade value above 0.1 btc and two xmr below 0.1 btc. In two of those cases the seller stopped responding despite the trade value being 2.6 btc and 1.95 btc. In one xmr-trade valued above 0.1 btc the seller confirmed in the chat for unclear reasons. Of the 23 fiat trades there is only one above 0.1 btc in value.

It is impossible to say for me if buyers that claim trouble or bugs are honest or not. In all cases they don't pay. One can also note that a seller can give wrong bank information in order to get the option of accepting a payment or not.

[wiz]

@flix1 Actually the founders of Bisq implemented a really cool BSQ reputation bond system, it's just not hooked up to offers yet, so it's not hard at all, we just need a way to associate bonds with offers, see #138 for one idea I had