Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Dispute mediator/arbitrator payout on trade WTZETDH #486

Closed
dcod3d opened this issue Aug 24, 2020 · 15 comments
Closed

Dispute mediator/arbitrator payout on trade WTZETDH #486

dcod3d opened this issue Aug 24, 2020 · 15 comments
Assignees

Comments

@dcod3d
Copy link

dcod3d commented Aug 24, 2020

Annotation 2020-08-24 104340

Maker: 25fb231915131bb7709a0e712a4e16258b2bc254d9f587359a9c09a85f3531f7
Taker: 9fe5e51eb0bf4a55c95eaf5109dc77b50a33f68a667b941dbc103a739a89f511
Deposit: 62fab1a4f1d1a47fb94dd1d372fc3f33a12eddfef9dbe31f89a0b0d43c6e0b4c
Refund: a1427e16a733dacebf9847b9a67e440fb76b692a804c60ac45e220a816d6de40

Mediator: @Bisq-knight

Buyer did not send payment and requested cancellation. I declined to cancel without some of the buyer's security deposit. The mediator's suggested payout was to return both parties' security deposit. I declined and requested arbitration. The arbitrator closed the ticket siding with the mediator (txid1b6f78b788f6689c9df70393d69e8ac28c686644ce54a236200a5ac8220fb9c3 | bisq-network/roles#93 (comment)).

Requesting 0.006 BTC or 97.53BSQ (30 day average 0.00006152) since the buyer never paid and I should've received their security deposit.

@dcod3d
Copy link
Author

dcod3d commented Aug 24, 2020

Additional Verification

Trade Wallet Address

-----BEGIN BITCOIN SIGNED MESSAGE-----
https://github.com/bisq-network/support/issues/486
-----BEGIN SIGNATURE-----
1GhpZzRDdBfqFVDbTCDhvp46nAWkGBV3GA
ILmhruqkclrnGEarrkrKwfxV1OGpsVZ14iP+ZDWaNKnqM5NXFFf4Cxp/5TQuR1LEOP0ZsDPQ2Kppd9T6ERzg1YM=
-----END BITCOIN SIGNED MESSAGE-----

Arbitrator Payout Address

-----BEGIN BITCOIN SIGNED MESSAGE-----
https://github.com/bisq-network/support/issues/486
-----BEGIN SIGNATURE-----
1PcgjzUYr7H9XjwN5UefyHDooph3FDw8tz
H3mkAFy2cgD5XKELK7+0885nqaJPByq6xsDJnwAbIQofW9Qgne0sfZ7NPnTkhh7OhEcQkrBR0fzXvnBBUWEksRQ=
-----END BITCOIN SIGNED MESSAGE-----

@ifarnung
Copy link

The security deposit was .006 not .06. This needs to be corrected to be considered on its merit.

@dcod3d
Copy link
Author

dcod3d commented Aug 24, 2020

Sorry, corrected and added the BSQ equivalent

@leo816
Copy link
Contributor

leo816 commented Aug 24, 2020

If the buyer stopped answering and didn't make the payment then it's pretty clear who didn't comply with the transaction. The seller did nothing wrong and he got penalized with time. The mediator should have closed the ticket in his favor. He even manifested how he wanted to continue with the trade and that if not, he should receive the other party's deposit.

@MwithM
Copy link

MwithM commented Aug 25, 2020

@RefundAgent Why did you follow mediator's suggestion?

@Bisq-knight
Copy link
Contributor

I believe we need to take a step back and look at this as a failure in our communication process.

The refund agent does not have access to the history of chats with mediator and has to rely on what I share with him (a summary of our chat).

I shared this:

sending your way a small but tricky case:
`WTZETDH`

the buyer started replying and then suddenly stopped. Now the seller got very motivated and wants to conclude the trade. 

The buyer's claim is that Zelle prevented him from sending the money. Then the Seller asked to get part of his deposit. When I tried to get a middle ground, the buyer stopped replying

some facts about this trade:

  • fiat payment was not made (no evidence was produced, nor receipt was confirmed)
  • traders did not come to an agreement on whether or not to cancel the trade and to what exact payout (they were haggling as who should get how much of each other's deposit
  • the trade did not go to arbitration automatically with the timelock (Seller had to manually broadcast the transaction through, which causes the case to arrive at the refund agent with information from only one side)

Did the buyer violate the trade protocol?

  • if we take his claim seriously, no. Because bank blocking the trade is not a violation of the trade protocol. Not sending the money is. But we have no way to verify that, especially if he stops replying (this in itself is a violation of the protocol) -> Simple cancellation would be the desired desired
  • if we only look at facts and ignore claims, yes. He did not send the fiat payment -> penalty to the Buyer is the desired outcome

current situation, looking only at the facts (Buyer did violate the protocol)

  • Buyer got his deposit back. If he violated the trade protocol, he got away with it. We need to focus on preventing this
  • Seller didn't get compensation for his time and troubles off the Buyer's deposit. He is the one who hurt in this

proposed solution

1 - Buyer getting away with violation -> we keep an eye out for his Tor address and be extra careful whenever he shows up again in the dispute process. But there's not a lot we can do for that apart from the above AND following the standard @leo816 is formalizing for cases of unresponsiveness
2 - DAO should not pay for this. This proposal should be rejected
3 - Refund agent already puts his Bitcoin on the line to make the process work. He should not have more layers of risk added to his role.
4 - I as the Mediator of this trade will pick up the tab and pay him the requested BSQ. As it was my responsibility to uncover the facts of the trade within the timelock period. All necessary facts were not uncovered (97.53 BSQ + 2 BSQ of issuing the proposal)

I pay him out of my pocket as it was my responsibility to arrive or uncover a suggestion for the refund agent. Without such suggestion he took the safe choice (with least damage to both parties) of a simple cancellation with each trader getting their deposits back.

next steps (of my suggestion)

  • Upon DAO rejection, @ncstdc should post a BSQ address in this thread
  • I will transfer the agreed amount (99.53 BSQ) and post the transaction ID here
  • @ncstdc will write a receipt message and sign it using keybase's @dchoe (as he has verified the account who initiated this thread and has also verified that it is trader from the above mentioned trade)
  • I will post this signed message on this thread for reference and cryptographic proof

@dcod3d
Copy link
Author

dcod3d commented Aug 25, 2020

Correct, the buyer messaged me that he was having issues with his bank. I told him to not worry about the trade deadline and I can wait. The buyer then initiated mediation a few days later. The mediator asked if I wanted to cancel the trade. I said I would agree to cancel for 50% of the buyer's security deposit. There was no more communication for over a week. When I asked for an update, the mediator said that the buyer had also stopped communicating with him and that the trade would go into arbitration after 20 days. As the 20 days neared, I did ask for the trade to go to arbitration since no progress was being made. The mediator showed me how to broadcast the delayed payout transaction to send the trade to arbitration.

My issue is with the mediator's decision (as stated in his first bullet point)

bank blocking the trade is not a violation

This should be a non factor. First, it is the buyer's responsibility to be able to send payment. Second, like he said, this is probably not even possible to verify.

Not sending the money is.

Violation #1

stops replying

Violation #2

Simple cancellation...

The buyer violated the trade protocol twice and decided simple cancellation was the best (and eventual) outcome.

As for the arbitrator. I sent him one message with a brief summary and that I did not want the trade cancelled. The arbitrator just closed the ticket a week later cancelling the trade with no other communication.

At this point, my issue is more in principle that a trader that does not violate the protocol is still penalized (time, mining/trade fees).

@leo816
Copy link
Contributor

leo816 commented Aug 26, 2020

@Bisq-knight Thank you for making this proposal and setting an example. I also think this will be the best outcome. Mistakes are bound to happen every once in a while and we have to continue make an effort to reduce them as much as possible.

@Bisq-knight
Copy link
Contributor

Replying your points one by one:

bank blocking the trade is not a violation

  1. The trade protocol also needs to leave room for us to learn, develop it and the bisq application further. If we make bank blocking a violation suddenly all users using revolut would have been violating the trade protocol when they introduced a new UI a month ago. We need to leave room for this rule as it gives us signal as to what we should change or not. Or would you prefer to alienate users in their first issue with the bank? (I've been banned by multiple banks already)

The enemy is not the other trader, it is the bank. and we need to figure a way to route around them.
If you really have an issue with that, please write a proposal and send it to the DAO on how stringent we should be and we put it up for the community to decide. I also think that if suddenly we start getting a lot of cases with people who claim to be getting blocked by their banks we will implement more strict procedures to prove that, like we have for providing proof of a bank transaction being made.

Both of the violations could've been fixed with more time (especially since you told him time was not an issue). I don't like trades to drag over their period but you did tell him that. The fact is: this guy can show up in a week saying that he would've complied with our suggestion anyways.

That is all besides the point now because a payout has been made and a mistake as well. We all agree that Buyer violated the trade protocol and Seller should've gotten his deposit. I proposed a way for you (@ncstdc ) to get whole. Do you agree with that?

If yes, we can then just wait for the vote reveal to carry out the compensation.

As for bisq itself we are already in the process of developing guidelines for situations like these. I also believe that the choice we make today will be taken as reference for the future:
"Facts that prove trade protocol violations should lead to penalties, claims do not invalidate the penalties"
(I suggest we discuss and define what is a violation on a different thread in the /Proposals repo, so it gets proper visibility)

@m52go
Copy link

m52go commented Aug 28, 2020

@Bisq-knight appreciate your feedback and offer to make @ncstdc whole. Whether or not this proposal is approved would appear to set a precedent for the level of mediator skin-in-the-game going forward.

For this particular case I think leo816 summarized everything quite well above.

The enemy is not the other trader, it is the bank.

This might be true in some cases, but I don't think it should apply to Bisq trades. As mentioned above, bank issues are unprovable. As bad as banking systems are, they usually work. The outcome of accommodating bank issues is probably going to be...more bank issues suddenly popping up.

Buyers need to use payment methods that work well for them, they need to be aware of their sending limits, etc. I think making carve-outs that take buyers off the hook in case of bank issues is a slippery slope that will degrade the trading experience.

@dcod3d
Copy link
Author

dcod3d commented Sep 3, 2020

@Bisq-knight
B1NDgQp5kwsvhi54C9fdCu6iVofrhdqFLeV

BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zkMSgn74 Xxuz24vH9WotxBm 3YoBh87TWFKVPGP fRr9Keza1KOEDYM QVp6gIu9IqvwSEk RB3HsECH9ppgFp8 RNYZ7sSGmsiSDvF urPfEe2gkBtbnTo CMbb06ZtzDUbRHc irfVB9j3nz8uIGb xDLlNs87sMHRuhH MBZ9ddxjHc33WIR e4ecDbsV7TDXx1u 3YFQD1SQXKeTZYu 7awnJJQ6. END KEYBASE SALTPACK SIGNED MESSAGE.

@chimp1984
Copy link

Thanks @Bisq-knight for your proposal and taking responsibility.
The new feature for detecting option trade should help to separate real bank issues with pretended ones.
The summary note should always give a correct sumamry of the case. The arbitrator will receive that summary note when a dispute gets to him, so that should help as well to avoid such situations in future.
This case shows that even mediators are not part of the transaction they carry some financial risk in case of mistakes. All persons working with financial risks and responsbibilities are usually getting that reflected in their payment as well. I am not sure what are the current compensation but I think it has to reflect that.

@Bisq-knight
Copy link
Contributor

Just following up on this. The proposal has been rejected in the DAO and @ncstdc has provided the address above and I have verified it on KB with the signature of the account who has contacted me, which proofs the GH account of @ncstdc agrees with what the account on KB discussed with me.

  • Upon DAO rejection, @ncstdc should post a BSQ address in this thread
  • I will transfer the agreed amount (99.53 BSQ) and post the transaction ID here
  • @ncstdc will write a receipt message and sign it using keybase's @dchoe (as he has verified the account who initiated this thread and has also verified that it is trader from the above mentioned trade)
  • I will post this signed message on this thread for reference and cryptographic proof

I will initiate the transfer to @ncstdc and post the details here as agreed

@dcod3d
Copy link
Author

dcod3d commented Sep 14, 2020

BSQ Received from @Bisq-knight
BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zkA8ZpUo 1Vb2qdkYgyBpM9i 5ZLm95DPnQliecp D0l02sbKb9qz5Py pVhnIVocAIlXmXo F80iA42Duexh8yJ JP0EbQJzbzws8qx Qk8NDzgsfjmSf8y ni7PiPEfFA2rtbW G0QCi95IUBjI5Gs LwImguAYZcIyuNu 6Z3C7HduOQwudjX exHBHTcCcJm88iB 1KQfD9iRKFxA0MX U. END KEYBASE SALTPACK SIGNED MESSAGE.

@dcod3d dcod3d closed this as completed Sep 14, 2020
@Bisq-knight
Copy link
Contributor

Just reposting so it cannot be edited:

BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zkA8ZpUo 1Vb2qdkYgyBpM9i 5ZLm95DPnQliecp D0l02sbKb9qz5Py pVhnIVocAIlXmXo F80iA42Duexh8yJ JP0EbQJzbzws8qx Qk8NDzgsfjmSf8y ni7PiPEfFA2rtbW G0QCi95IUBjI5Gs LwImguAYZcIyuNu 6Z3C7HduOQwudjX exHBHTcCcJm88iB 1KQfD9iRKFxA0MX U. END KEYBASE SALTPACK SIGNED MESSAGE.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants