Add delayed refund transactions

[chimp1984]

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

As we still have many cases (17 our of 42) in last cycle (bisq-network/roles#93 (comment)) where sellers (or less often buyers) are not responding we could add 2 more delayed payout transactions to the trade protocol with longer delay than the normal delayed payout tx which goes to burningman.

1. Delayed payout tx to burningman with delay 10 days for altcoin/20 days for fiat
2. Delayed payout tx to buyer in case seller is not responding with delay 15 days for altcoin/25 days for fiat. So the seller has still 5 days time to publish the delayed payout tx to the burningman and open arbitration. If a seller is not responding the buyer can avoid arbitration and wait 5 days more and if the seller still has not reacted the buyer will publish the tx to his favor.
3. Delayed payout tx to seller in case buyer is not responding with delay 20 days for altcoin/30 days for fiat. Same like above just opposite roles.

This would reduce arbitration cases and the hassle to convert BTC to BSQ and issue later a reimbursement with all the volatility problems involved.
I am not sure if it could be deployed without a trade protocol hardfork but i guess it could.
Just wanted to share first the idea to see if that gets support and if there are any security risks.

The only risk I see is if one trader could not user Bisq for certain reasons (lost wallet, was serious ill). In such cases the funds might be lost to the other trader, but that is also the case now with arbitration as soon the arbitrator has done the payout which could even happen faster then the 5 or 10 days extra delay or by DAO reimbursement (which would likely take longer).

[mpolavieja]

For Sellers of BTC for fiat, if the buyer does not respond but did send the funds (he did not press the "payment started" button), should Bisq advise the seller to return the fiat funds to the buyer, to avoid legal responsability as much as possible?

[MwithM]

@mpolavieja A buyer who did pay has responded in a certain way. If he did not press the payment sent button or there's a bug but does not report it, seller should be able to finish the trade normally and penalize the other part.

@chimp1984 A case like bisq-network/support#752 could not have been solved gracefully if the buyer had the option to unilaterally send a delayed payout to himself instead of being force to open arbitration. This case it's not so edgy, as mediators often do manual payouts for traders who have lost Bisq data and thus the possibility to act normally in a trade (confirm payment, press payment sent button) but still have the private keys.

Those users who completely forget about the trades are really annoying, as they lose a lot of money in the way.

[mpolavieja]

seller should be able to finish the trade normally and penalize the other part.

The "risk" I see is that the seller does not finish the trade normally and uses the delayed tx to get both the fiat and the BTC back.

I don't know the details of the delayed payout tx, sorry. Does it send the BTC amount of the Tx to the seller or to the buyer? If the former, I think that if the seller is getting his BTC back, it is fair that he gets the buyer's deposit, but maybe Bisq should advise the seller to return the fiat funds if he has received them to avoid legal risks.

[chimp1984]

@mpolavieja I agree that it woud be more fair and safe to send back the fiat in that case and we can recommend that, though Bisq has not way to enforce it.

@MwithM
How often does it happen that traders lose their data? I assume that is a very rare case, in the case you posted it is veyr bad as it is a 2 BTC trade. But I am not sure if we should consider such exceptional cases. There is also still the chance that the peer is honest and would not publish the tx or opens normal arbitration. If the seller get at least in touch with the community he has some good chances that the peer is honest (the majority of Bisq users have acted honest in cases where they could have taken profit - like when mediators/arbitrators did a wrong payout).

Another potential soution would be to publish the delayed payout tx to mediators or arbitrators so they could play the role of publishing that so if the trader who lost his data manages at least to contact them he is safe.

[MwithM]

I don't think that it would be so rare. There's many cases where one trader is unable to continue through a trade and mediators need to do a manual payout. The incentive for the trader who has the data to publish the delayed payout in their favour and not cooperate with mediator would be very big. An attacker could exploit Bisq to make the other node fail and send the delayed payout to himself.

Your potential solution, as delayed payouts are already signed, could make mediators once again be seen as money transmitters. They would be holding a signed transaction to send locked BTC. It's still not a private key, but they would have a way to benefit one of the traders (or Bisq, if you only enable them to use the delayed payout number 1).

[ghost]

I interpret the spec as:

• 1-20 days Trade can be completed amicably (happy path).
• 20-24 days Either peer can open arbitration.
• 25-29 days Buyer can txfr multisig to himself.
• 30+ days Seller can txfr multisig to himself.

I think it would not significantly reduce arbitration cases enough to make it worthwhile implementing.

In trades that go wrong money is on the line; people are nervous and want to quell the anxiety as soon as possible. Mediation & Arbitration solves that.

99% of people would open arbitration as soon as feasible, only 1% would have the balls to skip arbitration, wait it out to pay themselves.

[mpolavieja]

though Bisq has not way to enforce it.

I know. I just suggest that Bisq advises the user

[chimp1984]

@MwithM

could make mediators once again be seen as money transmitters.
I doubt that this can be interpreted as money transmitter as they have no controlling power. If so they each miner is mt for all mempool txs as well.

They would be holding a signed transaction to send locked BTC. It's still not a private key, but they would have a way to benefit one of the traders (or Bisq, if you only enable them to use the delayed payout number 1).
Hmm... I still doubt that would trigger liabilities but to avoid those grey area we could broadcast the tx to the whole network as well. Privacy is not changed much by that as a Bisq trade tx on the blockchain can be identified by its structure anyway relatively easy.

@jmacxx
Yes for fiat thats the spec. For altcoins its 10 -> 15 -> 20. We have more cases where the seller is not responding.

I think it will require a good description in the popup text when arbitration can be opened. There are clear benefits for users so I think if we comminicate that well they should benefit from that feature. Also mediator need to help to make it clear to traders that next step is not to open arbitration in case the peer is not responding but to wait 5 days longer and get refunded without further hassle. Also we could add in mediation a flag so that this option will only be offered in those cases where one trader is not responding at all.

Proposal for text:
"Your trading peer has not responded at all in mediation and has not accepted the suggested payout from the mediator.
You can either open an arbitration case now and publish the delayed payout transaction to the burning man and if your case gets support from the arbitrator you get refunded by the arbitrator [if amount > 0.5 BTC -> refunded by the DAO].
To avoid that extra delays and complications you can also wait 5 days longer and if the peer has not opened arbitration in the meantime you can publish another delayed payout transaction where you are the receiver of all the funds of the deposit transaction."
Steve can make that for sure much more readable but I think it makes clear that its only a benefit to the trader and has no risk involved.

But I agree it adds complexity and thats not great. But what are other solutions to reduce those cases of not responding traders? It is 17 out of 42 cases last month. We increased already security deposit but it seeems it dit no had effect on that.

[Conza88]

As we still have many cases (17 our of 42) in last cycle (bisq-network/roles#93 (comment)) where sellers (or less often buyers) are not responding

Tangentially related to addressing these issues:

• Improve communication between traders once offer is taken (#5074) [Improve "Portfolio" icon to aid communication between traders]
• Improve communication between traders & arbitrators/mediators if any escalations (#5044) [Add ability for mediator's & arbitrator's to see "Trader Chat" (upon escalation)]
• Improve notifications for agents/mediators/arbitrators (#5097) Add Notification icon for Mediation and Arbitration chat

[sqrrm]

Step 3 in this scheme isn't safe. A buyer could just be unresponsive for 25 days and then send the funds to themselves. The seller have no way of telling if the buyer's silence is malicious or not so the seller has to take the case to arbitration.

This problem was touched on in #279 (single tx trade protocol). It would be possible to add an intermediate step to handle this:

1. Day 0: trade initiated. Two symmetric payout transaction paths are presigned, first step can be published after 20 days
2. Day 20: either peer can publish their payout path
   i. Buyer publishes their payout of the deposit tx
   ii. Seller publishes their payout of the deposit tx
3. Day 20-25:
   i. Seller can spend the tx from 2.i to initiate arbitration.
   ii. Buyer can spend the tx from 2.ii to initiate arbitration.
4. Day 25+:
   i. Buyer can spend the tx from 2.i to themselves, if arbitration wasn't initiated by seller.
   ii. Seller can spend the tx from 2.ii to themselves, if arbitration wasn't initiated by buyer.

With this kind of protocol there is no risk of either party staying silent to trick the other to wait and avoid arbitration. Once the intermediate step is published after day 20 it's up to the other peer to take it to arbitration or lose the funds.

This protocol adds another 1.5 rounds to the trade protocol if I remember correctly. That's an added risk of trades failing during the take offer process.

[chimp1984]

@sqrrm

A buyer could just be unresponsive for 25 days and then send the funds to themselves. The seller have no way of telling if the buyer's silence is malicious or not so the seller has to take the case to arbitration.

Ah true.

An alternative would be to only support buyers with not responding sellers. So there is no step 3. The case that the seller is not responding seems to be the dominant one.
The benefit would be that it would require potentially less change in the trade protocol (probably no extra roundtrip needed as it just adds another delayed payout tx). Though not sure about that as this new tx is in favor of the buyer and the seller has incentive to not sign that and send it back to the buyer. But in that case the buyer would not start payment and it would lead to a failed trade. But would need more thought how it fits to the protocol...

But I agree its not great to cover only one side.
I am just not sure if the potential reduction of arbitration cases by 30-50% justifies a protocol change and potential trade protocol hardfork with all risks included and as we have seen in the past those changes always caused quite some troubles both with new bugs, security vulnerabilities and loss of trade volume.

[MwithM]

I am just not sure if the potential reduction of arbitration cases by 30-50% justifies a protocol change and potential trade protocol hardfork with all risks included and as we have seen in the past those changes always caused quite some troubles both with new bugs, security vulnerabilities and loss of trade volume.

I don't think so.
If Bisq takes a part of the security deposit of the unresponsive trader, that would at least cover the cost of arbitration. The risk that burningman creates as central point of failure will exist with or without these cases.

[chimp1984]

The risk that burningman creates as central point of failure will exist with or without these cases.

Yes. We should try to find a solution where the BM role vanishes completely for that part of his role. So far no idea is found. The optimization to reduce the cases is good but maybe not worth the effort/risk.

[stejbac]

I share @MwithM's concern that a trader may be unable to publish the delayed payout tx, say due to losing all his trade data, and then the counterparty can just wait and send all the funds to himself. (There would likely be at least a little temptation to do so if it was a large amount of BTC, especially knowing that the victim would be reimbursed by the DAO.)

I like @sqrrm's idea of giving each trader a separate delayed payout tx that sends the locked funds to a half-way address, before sending them on either to oneself (after a 5 day time delay) or immediately by the counterparty to the donation address. This is vaguely reminiscent of the two prepared uncooperative channel closure txs for a lightning channel, where the 5 day timelocked payment to oneself is analogous to the final settlement payout of the lighting channel, and the immediate remedial payment by the counterparty to the donation address is analogous to the hashlocked remedial/punishment payout (following a fraudulent channel closure) by the counterparty to himself, but without the hashlock. Just like the lightning channel protocol, I would be inclined to use a P2WSH half-way address with a custom script using OP_CHECKSEQUENCEVERIFY to enforce a relative 5 day time delay, rather than using the absolute block height of a downstream prepared tx locktime. This has the advantage that there's no hurry to publish the initial delayed payout tx.

It should be possible to mostly solve the problem of a trader losing their trade data and being unable to publish the time sensitive remedial downstream payment tx to the donation address, by burying the data needed to reconstruct it in their own signatures (say one for the deposit tx and one for the initial delayed payout tx). Because each 512-bit ECDSA signature (r, s) is derived from a 256-bit nonce k, where r is the x-component of the elliptic curve point R = kG and s = (z - re)/k, for a private key e and message hash z, it is possible to recover k from the private key, which is in turn derived from the wallet seed phrase. Thus 256 bits of arbitrary data may be buried in each published signature and recovered knowing only ones seed phrase. The remedial tx needs 512 bits of stored trade data to recover it, as it has to be signed by the counterparty, so that could be buried in the trader's deposit tx and initial delayed payout tx signatures. (The signatures can be malleated by the counterparty prior to publishing, but only to a very limited extent, so the 256 buried bits can still be easily recovered by brute force.) In this way, a trader who lost his trade data (and backups) should still be OK, provided he didn't lose his Bisq wallet seed phrase.

[chimp1984]

Ah interesting idea to use the signature for data recovery!
If we assume that the user has access to his seeds we could also use it for encypting the deplayed payout transactions and share it either with the mediators or keep in in the network for a certain time period (e.g. using TTL).