Allow "freezing" an order if it's in dispute

[Catrya]

Sometimes a user may open a dispute because they believe their counterparty is trying to scam them. If the dispute is easy to resolve and the user opens it well before the hold invoice expires, the admin handling the case can resolve it without issue. However, there may be cases where the dispute is more complex, for example, if the evidence provided by the users is inconclusive and the admin needs to request more proof or a bit more time. If the hold invoice expires before the admin can reach a decision, the sats will automatically return to the seller, potentially unfairly.

Another possible scenario is when the fiat takes longer than usual to reach the seller, such as due to delays in bank processing. In these cases, the buyer runs the risk that the seller won’t receive the fiat before the hold invoice expires and, therefore, won’t release the sats. But once it expires, the seller gets the sats back, and eventually also receives the fiat. The buyer is then left at the mercy of the seller's goodwill, who may or may not decide to send the sats manually, with no way for Mostro to intervene.

To avoid these situations, a new feature should be implemented: if an order is in dispute, the solver/admin handling it should be able to "freeze" the order. This means the Mostro node would settle the hold invoice but would not pay the buyer immediately. The order will have a new status frozen. Instead, the sats would be held until the situation is resolved and the admin makes a final decision:

• If the admin decides the sats should go to the buyer, Mostro should pay the invoice the buyer provided at the beginning of the trade (if too much time has passed, the invoice may have expired, in which case Mostro should ask the buyer for a new one).

• If the admin decides the sats should go to the seller, Mostro should request a new invoice from the seller for the total amount of the order.

In @lnp2pBot, the function used to freeze an order is called freezeorder, and the one used to pay the buyer’s invoice is called paytobuyer. However, when the sats need to be returned to the seller, the process is currently manual. It would be better to automate this so that Mostro itself requests an invoice from the seller, rather than the admin doing it directly. What do you think about this last @grunch Or do you think that for now it is better to make returns manually like in the bot?

[arkanoider]

I was looking into this in these days in my spare time, @Catrya let me know if I understand the flow:

• This is introduced to avoid expiration of hold invoice while the trade is still open, examples are the above ones: long dispute, long fiat payment processing...
• to avoid that we have to settle (pay) hold invoice but the order is a new state called frozen, this is a command can only admins (solvers) can send to mostrod, right?
• when order is frozen admin can decide who is the "honest" one and so decide to settle order in favour of one or another:
  • in case the buyer is hones paytobuyer command is used from admin and sats are release to the original added invoice from buyer
  • if seller is the good boy now bot has no automatic settlement, but admin must ask ( via tg chat??? ) an invoice to seller for refund.

Is my understanding right??

[Catrya]

Hi @arkanoider sorry for the delay, you're correct.

• Only an admin who handled the dispute can freeze an order, and only if the order is under dispute, not before or after.
• When the order is "frozen," the node charge the hold invoice (it will hold the SATs until the situation is resolved).
• Only the admin who froze the order can "unfreeze" it.
• If the admin decides the buyer was right (in the bot's case, the paytobuyer command is used), the order should be completed and the buyer's invoice paid normally.
• If the admin decides the seller is right, in the bot's case, the admin has to DM the seller to request an invoice. Perhaps in the case of Mostro, an add-invoice message could be sent to the seller. What do you think would be better in this case @grunch ?