Trading protocol change: release of funds in 2of2 multisig to be signed by seller in first place.

[MwithM]

With the objective to prevent seller from performing future trades, I propose to change the trading protocol to make seller be the first to sign the 2of2 multisig and let buyer sign the normal payout (buyer gets trade funds, both parts get their deposits back) at the end of the trade settlement.

This is how the trade protocol changes:

1. Buyer deposits +15% deposit and buyer deposits trade funds and 15% deposit.
2. Buyer sends fiat or altcoin payment to seller, press payment sent button and provides the first signature of the 2of2 multisig tx.
3. Seller clicks payment received, signing and publishing the multisig tx and provides the first signature of the 2of2 multisig tx.
4. Buyer signs and publishes the multisig tx, releasing deposits and trade funds.

With the current protocol, when buyer pushes the payment sent button, provides the first signature of the 2of2 multisig. Even if buyer starts a dispute, seller can just sign the second signature, overriding mediator's suggestion.

This proposal adds an extra step (number 4) that makes future trading riskier as it does not allow sellers to omit mediation, so in case he does not push the payment received button on time, he could loose the security deposit.
If, as proposed, buyer doesn't provide any signature when clicks payment sent, he will be able to open a dispute that will have effect. Buyer has more to loose in case of mediation after payment has been sent, so if he's the last to sign, we should expect buyer will release funds according to protocol.

[huey735]

This is a great flip in the power dynamics - to give the btc-buyer the chance to force the trade into arbitration. However I feel like it may increase the arbitration cases by a lot.

[luisantoniocrag]

I like the idea that they both have the same power and obligation by request mediation.

But it is not clear to me why this should be so.

BTC seller is who put most on the trade total funds + a security deposit.

And the seller also doesn't have an opportunity to revoke a payment or overdraw it.

If you could explain a scenario in which the current rules fell and ended in a bad trade, please.

[MwithM]

And the seller also doesn't have an opportunity to revoke a payment or overdraw it.

If Bisq used a stablecoin instead of a high volatile currency like BTC, this proposal would not be necessary.

My proposal missed on explaining different scenarios:

1. Buyer doesn't pay: seller demands mediation, gets a part of buyer's deposit, and his deposit + trade funds. In this point, buyer not pushing
2. Buyer pays but protocol has been violated by buyer (i.e. invalid reason of payment): seller demands mediation, gets a part of buyer's deposit, and his deposit + trade funds. At this point, buyer not pushing the "payment sent" button doesn't makes much sense, because he already paid and want the btc to be released.
3. Buyer sends a valid payment but seller doesn't confirm reception: buyer demands mediation, gets a part of seller's security deposit + trade funds, and his security deposit. At this point is where the proposed change makes effect: before, seller could delay to push the "payment received" button until timelock activation, as he already had 1/2 of the signatures required.
4. Buyer gets the notification that seller has pushed "payment received" button: if he makes the second signature, he gets trade funds + security deposit and seller gets security deposit. As buyer likes to get trade funds and security deposit the sooner as possible and has more to lose than seller, he has incentives to release the multisig funds as soon as possible. At this point, requiring mediation would only make sense if seller pushed "payment received" exceeding the trading period. In that case, buyer could receive a big part of seller's security deposit.

Is future trading still possible? Yes, but risk is higher. Now buyer can open mediation and seller will lose a big part of the security deposit (which, by the way, could be optionally higher than 15% in case buyers want higher protection from volatility).
Another way to reduce risk of future trading (and, if done right, improve user satisfaction) would be to reduce dispute resolution times.

[ricardosaurio]

Not sure if I get it correctly, but I would disagree, as usually sellers wait until last minute, not to do futures, but to avoid chargebacks, if applicable

[MwithM]

That should only be an issue using fiat with not signed accounts, but it's happening everywhere.
If seller lets the buyer know why is he delaying the push of "payment received" it should not make the buyer to request mediation, if he's being reasonable (i.e. buyer as maker, initiated the payment just a few minutes before the end of the trading period, or account is not signed yet).
Buyers are unprotected if sellers want to delay BTC release for 10 (altcoin) or 20 days (fiat).

[wiz]

@chimp1984 this is an interesting idea, would you mind giving your feedback?

[sqrrm]

The logic behind this proposal is sound. The buyer is signing a payout tx that's possibly worse than what he can get if the case goes to mediation.

The problem I see is that it adds an additional step to the trade process which is another step that can go wrong. As we currently seem to have quite a bit of trouble with message delivery it's probably best to not make that worse.

I think making the deposit amount dynamic should be the first step. Let it depend on volatility, this should alleviate some of the futures trading problems we have.

[chimp1984]

the objective to prevent seller from performing future trades

Future trades are usually executed by the buyer as he can decide to not send the fiat/altcoin payment. The seller is locking up initially his funds so he cannot "cancel" the trade by not pressing the "received" button, but only risks to lose his deposit if doing so. The buy on the other hand can opt out of the trade by not sending the fiat/altcoin if volatility is higher than his security deposit and therefore it is economically rational to do that.

I think the security deposit for the buyer should be higher than for the seller (as it was in the past). For seller the 15% is probably already pretty high. For buyer I would suggest to increase to 30% if no other solution is found soon. Once Refund agent revokes the current situation becomes a big problem if not solved in time.

[chimp1984]

Buyers are unprotected if sellers want to delay BTC release for 10 (altcoin) or 20 days (fiat).

What is the incentive for the seller to do that? He has received the counterpart and only risks to lose his deposit. Also he does not want to keep his deposit locked up longer as needed.

[MwithM]

Ok I get now that buyers are the ones in position to perform future trading, but still, it's happening without consequences.
Demanding mediation as a buyer makes no difference because seller can just ignore it, I don't know if that happens too often. It happened to me a couple times lately, once until the trade went to arbitration and another one for a couple days of delay (was supposed to be an instant trade). Mediators are aware of this and they let you know that there's no much they can do, which is frustrating. Even if plain negligence is causing this situations, it's unfair that only sellers can demand to be compensated for an unresponsive counterpart.

About buyer's min security deposit issue that arose, I think that letting users to choose is better.
Maybe leaving a 30% as a software default security deposit while it's still possible to opt-out, making it lower to 15% is a better solution. Also, if a volatility index solution goes on to calculate the correct security deposits, it should be just informative. Some orders are not placed to be taken instantly, others are not taken instantly even if the maker wants.

[chimp1984]

it's unfair that only sellers can demand to be compensated for an unresponsive counterpart.

What do you mean with that? If the seller is not responding he should lose his security deposit and the buyer will receive that.

For fiat trades which are usually small the 15% might be too low. We might need some more complex formula. E.g. a min. sec. deposit or a higher % for low volume trades for sellers. Buyers should be increased anyway. But also here for low volume 30% might be still too low. If one trades 50 EUR a 15 EUR loss might be not high enough to motivate to fulfil the trade obligations.
Downside is that it becomes more complicate for users to understand how high the deposits is, thats why we simplified in the past. But thats a UX problem and solvable IMO.

Regarding optional setting of deposit:
I think this is now with the new trade protocol more problematic as most traders do not understand the context and are prone to make bad choices without being aware of the consequences which can be external to themselves (e.g. refund agent gets more cases, other trader loses time).
And yes, it is difficult to estimate the required deposit based on volatility risk for makers as they never know when the offer is taken and what the volatility will be then.

[MwithM]

If the seller is not responding he should lose his security deposit and the buyer will receive that.

Yes, buyers should be compensated, but they aren't. Mediator's suggestion can't protect them because sellers can click "payment received" even after mediation has been announced, just as long as it's before the timelock for arbitration can be activated.

I received this answer as a buyer, after providing proof of payment to the mediator: "okay but not much i can do at the moment, we need to wait for him to respond during first 10 days"

[chimp1984]

@MwithM
Ah ok. But I assume you had bad luck here. I don't see any incentive for the seller to not release immediately. Maybe to gain a bit more security against chargeback risk might be the motivation?

We could change the UI so that after a mediated suggestion is published the seller cannot click the button anymore. Even that is not bulletproof (trader could manipulate the code) I think it would mitigate that problem to 99.9%.

[clearwater-trust]

The seller should be able to keep the trade open with no mediator or arbitrator involvement until the full trade time is expired. This should be expected behavior by the buyers (Seller keeping funds until they feel confident the banks won't chargeback the funds.) Really, the best way to fix this problem is to remove the mediator?

[MwithM]

It did happen with altcoins only. I find logic that when I'm buying fiat the seller would preffer to prevent a chargeback delaying the BTC release, as long as he explains that in the trading chat.
Modifying the UI looks good to me. If this keeps happening we will narrow the field to detect if there's an incentive on voluntarily delaying the BTC release.

[deusmax]

In my experience, of a SEPA payment (fiat), going from 6 to 20 days seems excessive. Especially when the seller is unresponsive. On the other hand, I admit to being new in Bisq, so my understanding of the charge-back risk is currently limited.

Perhaps the documentation should be updated to note a transaction may take up to the arbitration period for the seller to acknowledge payment with no penalty. Practically, this means the standard the 1 or 6 days limits are recommended soft limits, correct ?

[MwithM]

Superseeded by project: bisq-network/projects#39