bisq-network / proposals

@bisq-network improvement proposals
https://bisq.wiki/Proposals
44 stars 16 forks source link

Proposal to increase trade deposit to 30% #233

Closed sqrrm closed 4 years ago

sqrrm commented 4 years ago

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 commented 4 years ago

@RefundAgent I think these can both be suspected as "option" trades:

8 buyer unresponsive or quit 5 buyer claims problems and does not pay

So if you consider 13 out of 28 cases could have been avoided by letting users cancel, that might lower Arbitration cases by 50% right there.

flix1 commented 4 years ago

8 buyer unresponsive or quit 8 seller does not confirm or respond.

16/28 (57%) are "unresponsive". This could easily be heavily penalized by awarding both security deposits to the responsive party. This could even be automatic, requiring little work from arbitrator/mediator/refund agent.

It would automatically: 1 Punish the unresponsive party. 2 Reward the responsive trader 3 Reduce workload for arbitrators. 4 Reduce total mediation time or at least make it predictable.

It also combines well with higher (voluntary) security deposits. It can be done with pre-signed txs so no need to change trade protocol or 2-of-2 multisig.

AND it does not require funds to flow through the donation address. So no centralized honeypot to hack, refunds to make or decisions for the DAO.

chimp1984 commented 4 years ago

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.

Thanks for the overview.

Is that distribution similar to the past months? I am surprised that there are so many seller not confirm cases. Could you post the data in more details to see amounts associated with issue (trade amount | cause for dispute)?

Those cases could be resolved by higher deposits:

8 buyer unresponsive or quit -> Future trade 5 buyer claims problems and does not pay -> Might be future trade where buyer is dishonest 8 seller does not confirm or respond. -> Here the trade amounts would be important to know. I assume with low trade amount/deposits they dont care enough. 3 seller confirms in chat. -> Can you explain more what that means? Seller did not confirm in app but in dispute chat? Why he did not confirm in app?

So we have 28% future trades, 17% likely future trades, 28% careless sellers (need more info to confirm assumption) and 10% likely careless sellers (need more info to confirm assumption).

If the above assumptions are right 83% could be avoided by a higher deposit.

I think it would be good to get a longer time period and more details from the data to be sure our analysis is correct before taking action, but so far the data confirmed our assumption that most cases could be avoided if deposit would be significantly higher.

chimp1984 commented 4 years ago

It also combines well with higher (voluntary) security deposits. It can be done with pre-signed txs so no need to change trade protocol or 2-of-2 multisig.

AND it does not require funds to flow through the donation address. So no centralized honeypot to hack, refunds to make or decisions for the DAO.

I dont understand how that could work from a technical and security point of view. If you refer to the closed proposal with SSSS, that got considered as unsafe and was closed after I posted my concerns. In short: pre-signed payout txs cannot be held by traders as that would incentivise them to try to execute the best outcome for themselves. If it is sent to a 3rd party we have a TTP problem and are back to old arbitration system but just with a more complicated implementation. The only way it could work would be if there would be trustless oracles and altcoin transfer could be validated in a secure way. But even there might be reasonable good solutions out there they might not be good enough when higher amounts are at stake. As well we don't have dev and research resources to go that direction.

chimp1984 commented 4 years ago

@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

The main problem with reputation is privacy. Reputation requires identity and that does not work well with privacy. So if you link offers to a bond, one could see all trades/offers of that trader. Once the trader get de-anonymised, all his trade history is public. The trade protocol v2 tries to solve that as well, but it is likely not feasible.

chimp1984 commented 4 years ago

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

"relatively easy" is actually a "pretty hard problem". See previous comment about identity and privacy. To get both is a hard problem. Sure we have account signing and that is a better form of identity than other forms but connecting that to offers/trades and preserve privacy is a challenge.

chimp1984 commented 4 years ago

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.

Yes I agree that would be a good option, and refunding a part of the deposit is important to give incentive to use the feature (as well mediators cannot do a payout suggestion with 0 BTC for one side to incentivise them to accept the suggestion). The current refund might be too small though (or overall deposit too small).

@RefundAgent I think that would solve quite a few cases as it would incentivise future traders to accept a small loss instead risking to go to arbitration and experience a larger loss. So our main problem of having too many cases would get support. Future trades would still happen but would turn more into a supported feature which might be easier to handle than a weakness in the protocol which we cannot avoid easily with punishment.

wiz commented 4 years ago

The main problem with reputation is privacy. Reputation requires identity and that does not work well with privacy. So if you link offers to a bond, one could see all trades/offers of that trader. Once the trader get de-anonymised, all his trade history is public.

Well sure, but obviously posting a bond is an optional thing, so if you care about privacy then just don't link your trades to a bond. But let's be honest, you can already do blockchain analysis to link multiple trades together unless you coinjoin before and after every single trade. So it's not like Bisq has perfect privacy right now anyway. I would be happy to link my trades together, and I would expect others would prefer to trade with me if I had a bonded reputation score, because they know I'm less likely to default on the trade and more likely to complete the trade quickly and without issues.

wiz commented 4 years ago

I dont understand how that could work from a technical and security point of view. If you refer to the closed proposal with SSSS, that got considered as unsafe and was closed after I posted my concerns.

You're right, the idea is still very early and not fully developed into something that can be implemented yet, but I feel it has potential. Maybe if we brainstorm on it together we can figure out the missing pieces.

flix1 commented 4 years ago

"relatively easy" is actually a "pretty hard problem". See previous comment about identity and privacy. To get both is a hard problem. Sure we have account signing and that is a better form of identity than other forms but connecting that to offers/trades and preserve privacy is a challenge.

I meant that Payment Account reputation is easier than User reputation... But yeah, it still brings a lot of privacy concerns. Agreed.

flix1 commented 4 years ago

In short: pre-signed payout txs cannot be held by traders as that would incentivise them to try to execute the best outcome for themselves. If it is sent to a 3rd party we have a TTP problem and are back to old arbitration system but just with a more complicated implementation.

@chimp1984

Sure, I meant that given that we do still have arbitrators, giving them signed txs, like we already do to send funds to the donation address, could open the door to more automated resolution and thus reduce workload for existing arbitrators which was the problem that this proposal brought up.

If the options are very clearly defined and based on objective parameters (eg: buyer/seller does not respond) it would allow the arbitrator to just click on a box and spend only a few seconds to resolve (once time runs out).

What's more this "multiple choice" conflict resolution would eventually open the door to automated arbitration once the API is up and running.

If the Trusted Third Party is an open source algorithm that would be very easy to scale.

Thinking particularly of XMR/BTC trades I don't see why we cannot fully automate it:

A

  1. BTC buyer does not make payment and time runs out
  2. BTC seller opens dispute
  3. BTC buyer does not respond and dispute time runs out
  4. BTC seller recovers funds and is also awarded buyers security deposit.

B

  1. BTC buyer does not make payment and time runs out
  2. BTC seller opens dispute
  3. BTC buyer responds and says they have paid
  4. Prompt requests BTC buyer to paste blockchain proof of payment
  5. Payment checked by program. --> IF paid THEN trade complete. -->IF NOT paid then trade failed. --> BTC seller recovers funds and is also awarded buyers security deposit.

C

  1. BTC buyer makes payment and time runs out
  2. BTC buyer opens dispute
  3. BTC seller does not respond and dispute time runs out
  4. BTC buyer receives BTC funds and is also awarded sellers security deposit.

D

  1. BTC buyer makes payment and time runs out
  2. BTC buyer opens dispute
  3. BTC seller responds
  4. BTC buyer responds
  5. There is a real bug or misunderstanding
  6. We are back to manual arbitration...

But from what @RefundAgent has said... it seems that case D is a very small minority of disputes.

8 buyer unresponsive or quit --> A 5 buyer claims problems and does not pay --> A? 8 seller does not confirm or respond. --> C 3 seller confirms in chat. --> B 1 genuine bank trouble. --> N/A to XMR/BTC
1 late payment --> B 1 genuine bug --> D 1 seller gave incorrect bank info. no trade occurred. --> N/A to XMR/BTC

@wiz I'm counting on you to poke wholes in this logic ;-)

RefundAgent commented 4 years ago

A more detailed breakdown of the latest disputes:

b payment problem did not pay 0.08 usd z s did not respond 1.95 xmr b did not respond 0.02 usd z s no confirmation 0.022 usd z b did not pay 0.0436 usd z b computer problem no pay 0.022 eur s b bug no pay 0.022 eur s b did not respond 0.165 usd z b bug did not pay 0.0725 usd z s gave incorrect info n trade 0.0144 eur HalCash b did not respond 0.022 eur s b did not respond 0.022 eur s genuine bug no trade 0.022 usd z seller confirmed in chat 0.08 eur 6 june s b bug did not pay 0.022 eur 3 june s b did not respond 0.022 eur 3 june v1.3.4 s s did not respond 0.033 eur s s confirmed in chat 0.022 eur revolut s no confirmation 0.052 eur s s no answer 0.0359 xmr s no answer 0.022 eur revolut s conf in chat 0.879 xmr s no answer 0.022 brl nbt bank name prob no trade 0.0471 usd z b did not respond 0.0189 gbp faster payment b did not respond 0.022 eur 21 may v1.3.4 s late payment 0.0426 xmr s no answer 2.6 xmr s no confirm 0.022 brl nbt s no answer 2.6 xmr s no answer 2.6 xmr s no answer 0.022 xmr b did not respond 0.022 eur s b refused to pay 0.065 eur s b did not pay 0.0219 eur revolut b did not pay claiming bug 0.022 brl nbt b did not respond 0.0219 usd z s could not confirm, bug 0.0377 usd z s did not confirm 0.052 usd 5 may v1.3.4 z some bug 0.014 bsq s could not respond 0.074 xmr b did not respond 0.016 eur s s did not respond 2.6 xmr 25 april b did not respond 0.022 eur sepa instant s did not respond 0.032 eur s did not respond 2.6 xmr s could not confirm, bug 0.237 eur 7 april, v1.2.7 s

The numbers are the trade value in btc, including the security deposits. In most cases (in particular with non-responding traders) the RA has no further information, and relies on the mediators suggestion. b means buyer and s means seller. The last entry is the payment method, s = sepa, z = zelle, nbt = national bank transfer

There are two problems. The first is too many mediation cases which will to some extent be solved with a "cancel trade" button. This will not solve the mispriced option problem. Sellers will leave Bisq when they discover that trades that will be concluded only if the price moves against them or does not move much. This problem can be alleviated either by having a correctly set security deposit or policing. Note that the price of options is high when the volatility is high and this is a real cost of volatility. The cost of a security deposit in Bisq is not very high since it corresponds to the lost interest during the trading time. A well-set security deposit will not only decrease the trading time, it will also incentivise the traders to publish offers which are close to the market price.

flix1 commented 4 years ago

Thinking some more about this... the closer we can get human dispute resolution to how a true oracle would work... the easier it will be in the future to remove TTPs completely.

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.

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.

I have to disagree with you @clearwater-trust. Unfortunately experience has taught me that any central point of failure will be attacked by regulators and they will impose KYC or censor the market. I have seen it a million times. But let me just point you to one example:

Shapeshift.

They had the best legal advice on how to not be custodians so that they would not have to do KYC. Erik Voorhees was adamant that they would never do KYC. He left NY after the Bitlicense was approved. They built it all the right way: no custody, no touching user funds, no accumulating user data, etc... They were so proud of their NoAccountNeeded hashtag!

The minute that their volume grew large enough they were called up and given a choice: submit or close. When you have employees, a company, investors... it's a very tough choice. Now they have KYC.

I am glad that the founders of Bisq have followed Satoshi's example and left. Otherwise they could be pressured.

It would be so easy for regulators to doxx a few dozen Bisq arbitrators to shut Bisq down or destroy trust in the market. They will be a target the minute that volumes grow to be significant.

flix1 commented 4 years ago

@RefundAgent thank you very much for the additional detail. This is very useful. Any chance that you would have info on payment methods? It would help test my theory that faster payment methods have fewer "future trades" problems.

BTW less than 30 disputed trades out of more than 3000 completed trades in the period is absolutely amazing! It gives me great hope that Bisq is on its way to success!

clearwater-trust commented 4 years ago

@flix1 Erik Voorhees is a Corporate Shill.

Bisq is not a corporation. Do not be afraid of the DAO. Let it be our guide in these matters.

Your blind faith in the machine world of code, as if it can someday replace people of good standing (and massive bonds), is disturbing.

You cannot code "the oracle".

A human arbitrator is just like a developer- with the arbitrator role.

@RefundAgent That is very helpful info. Thank you.

What are you doing with the security deposits? Why have you not posted a bond?

flix1 commented 4 years ago

@clearwater-trust Ignoring your ad-hominems and dismissive tone and moving past it to focus on the arguments...

10 years of experience in Bitcoin shows that every single exchange, be it centralized or P2P, has been pressured to become regulated or forced to close the moment that their volume became sufficient to merit attention. Being a DAO affords some protection, but it is not a complete safeguard. The day a terrorist is caught using Bisq there will be headlines and there will be massive regulator scrutiny. As Bisq grows to 100.000s of users the probability of a bad actor being among them approaches 1.

100s of years of contract law shows what even with recourse to human judges and arbitration, the simpler and clearer a contract is, the easier it is to enforce and the less need for dispute resolution. Since the problem here as referenced by @sqrrm at the top is too many disputes... I think that simplifying and clarifying the Bisq contract is a good direction to go regardless of whether an ultimate goal of full disintermediation can be reached.

If it could be reached (I'm definitely not certain that it can and have no blind faith in perfect code) it would be very superior to a system with TTP. Even if it can only be partially reached (say 99% of cases are automatic and only 1% of disputes require TTP intervention) it would still be a major breakthrough.

In fact Bisq already achieves over 95% P2P trades without requiring mediation or arbitration. 1 arbitration case a day is a huge success. If we can get it down to 0.1% we would have gained a lot.

clearwater-trust commented 4 years ago

100s of years of contract law...

Corporate Law is Over! They are all going to hell where they belong! Don't get stuck in the past.

We have real accountability on our side!

Use the DAO!

RefundAgent commented 4 years ago

Introducing a "cancel trade" button makes the offers into options also for the seller and the security deposits should be symmetric. It will make the offers more similar to American options (with a user-chosen expiration date) than European options (with a fixed strike date). I assume here that both traders can choose to cancel the trade.

@flix1 Payment methods are now in the data.

sqrrm commented 4 years ago

@RefundAgent with the PR Deposit improvements that introduces symmetric deposits and Add feature to cancel a trade being worked on I think that's what we'll have.

MwithM commented 4 years ago

I like the ideas on the Deposits pull request because it still leaves the option to use the 15% security deposit and only suggests a security deposit based on current volatility.

But still, sellers stop answering and they can omit mediator's suggestion: that's as critical as the security deposit, maybe even more. Symmetric deposits won't help buyers if sellers are not accountable when they don't follow the trading protocol. To fix this, a software lock seems good ennough

Furthermore, I'd like to study a few changes for arbitration:

  1. Reduce timelock trigger time, to reduce collateral needs and let users get back their money earlier.
  2. Copayment for arbitration, to make the costs of arbitration more explicit.
  3. Allow more than 1 arbitrator, to reduce the high amount of capital needs for this role.

We should keep discussing at #proposals channel the pros and cons of this changes, and what numbers should be used. I'll make the proposals after considering your points.

chimp1984 commented 4 years ago

I assume here that both traders can choose to cancel the trade.

If we allow that we must make very clear that buyer only can accept cancelation if he has not started payment yet. If users read instructions that should be not an issue, but we know they often don't read and it might be just a new source of problems. It also would increase number of "option trades" which should be not the preferred operation mode in Bisq. It might be frustrating for users who just want to get in or out of BTC to be the "victim" of speculative traders and might decrease user experience for such traders. I think we should only use the cancel button for the buyer as we cannot avoid option trades in that case.

MwithM commented 4 years ago

Closed as approved (with several changes from the original proposal): https://github.com/bisq-network/bisq/pull/4347