Add option for mediator to resend PeerOpenedDisputeMessage to non-resposive peer.

[ghost]

Description

Described here by @pazza83, user may never receive mediation ticket if issued in the middle of them performing an SPV resync. This is because their Bisq instance is up / receptive but the infrastructure components are not active / listening, so any protocol messages received during an SPV resync are dropped.

• Alice and Bob have a trade in process.
• Bob restarts Bisq for an SPV resync (which is a lengthy process), then Alice opens a ticket with the mediator.
• The mediator relays the ticket to Bob by sending PeerOpenedDisputeMessage while he is in the middle of syncing the chain.
• Bob never receives the mediation ticket message, (message is received by the low level Connection class but there is no listening infrastructure to process it).

Bob is unaware that mediation was started, and mediator is unable to communicate with Bob.
We need Bob to get a mediation ticket in order to resolve his trade.

From @pazza83:

Mediator will always try to send a message again if a trader does not reply.
Could something be done on the subsequent attempts? Maybe checking to see if a mediation ticket exists on the traders instance and opening one if that is not the case.

Proposed solution

Allow the Mediator's instance to:

1. Detect that there is a problem communicating with Bob on the ticket (no dispute chat msgs have been ACKd).
2. Prompt to re-send the dispute ticket PeerOpenedDisputeMessage to Bob.

Considerations

This proposed change, being a special case (as with most bug fixes) would slightly increase complexity in the DisputeManager code. I would like concept approval from a reviewer before proceeding with the solution.

[pazza83]

This would be a useful feature.

Occasionally myself an @leo816 have missing mediation tickets for one of the traders.

@HenrikJannsen is this something you can review?

[HenrikJannsen]

Another option would be to not start the P2P network when doing a SPV resync. Would also lower CPU usage. Not sure how complex that would be and if it would have follow up issues. But maybe worth to look into.

[ghost]

@HenrikJannsen An SPV resync can be initiated from the GUI or from the filesystem. Users sometimes have to do it from the filesystem because their Bisq app won't start otherwise - for example if BitcoinJ is reporting an error. If the latter option is chosen the Bisq app has no knowledge that an SPV resync is underway -- and no way of deciding whether to disable the P2P network.

[HenrikJannsen]

True. So then this option has to be dropped. Then your suggestion is probably the best we can do.

[pazza83]

Would be good for this to be implemented.

I had 3 cases this cycle of missing mediation tickets. All were resolved when the users opened mediation on their instances and the ticket appeared (on both their and my instances).

Not sure it is always an SPV resync that causes this. Maybe there are other reasons the peer does not receive the message to open a mediation chat.

There was also once case where a user sent a trade to arbitration and a ticket was not opened on their instance. Error message was:

Achtung
Das Handels-Protokoll hat ein paar Probleme gefunden.

Während der Ausführung des Handel-Protokolls ist ein Fehler aufgetreten.

Fehler: An error occurred at task: PublishedDelayedPayoutTx
TxBroadcastException{
     txId='013cd6476e8db260307c007736a00eed297bca58268773395a92a27de7591d8e'
} bisq.core.btc.exceptions.TxBroadcastException: We got broadcastTx called with a tx which has an open timeoutTimer. txId=013cd6476e8db260307c007736a00eed297bca58268773395a92a27de7591d8e

Es kann sein, dass dieser Fehler nicht gravierend ist und der Handel ganz normal abgeschlossen werden kann. Wenn Sie sich unsicher sind, öffnen Sie ein Vermittlungs-Ticket um den Rat eines Bisq Vermittlers zu erhalten.

Wenn der Fehler gravierend war, kann der Handel nicht abgeschlossen werden und Sie haben vielleicht die Handelsgebühr verloren. Sie können eine Rückerstattung der verlorenen gegangenen Handelsgebühren hier erbitten: [1]
[https://github.com/bisq-network/support/issues]

It is an unconfirmed DPT not sure if the additional time some the deposits take to confirm cause problems with the messaging system also? Does the client treat the lack of confirmation for multiple hours as a failed transaction, when it is just caught up in the mempool queue?

@jmacxx could the proposed solution also be applied to arbitration tickets also? This would mitigate the chance of off Bisq reimbursements from being needed.