Fix user frustration due to non-responsive makers: add option in sendpayment.py to automatically retry if makers don't respond

[icy-ux]

Why this is needed

Sometimes a taker transaction will fail because makers failed to respond. Under certain network conditions (further investigation is required to determine why) this will happen many times in a row.

Manually retrying sendpayment.py is extremely time consuming. The user has to be present at the keyboard, waiting for the transaction to fail, and waiting for the stall detection logic to time out. If makers keep failing to respond, the user will probably give up entirely.

Proposed solution

Just as sendpayment.py has a --yes option, it should have a --autoretry option (which implies --yes) and which will cause it to keep retrying if the transaction fails due to counterparty unreliability.

This option could also apply to other common scenarios where the sendpayment.py script is failing but where simply retrying is likely to make the transaction go through.

[AdamISZ]

I think functionally this was a sensible idea; I didn't pick it up immediately at the time because I remember there are several tricky nuances around this.

Unfortunately as is often the case if I or Kristaps don't pick it up, it just gets ignored.

As you can see here, we do retry if the failure is in phase 2 (the phase where the makers send over signatures to the taker):

https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/537d2acfec612bcc424a40e6f5fb3ac19293da6b/scripts/sendpayment.py#L292-L320

One reason for this choice is alluded to there: tumbler has a specific concept of 'tweaking' the schedule, allowing you to change the number of counterparties or the coinjoin amount before retrying, on the assumption that that will probably increase the chance of success. Given that, it felt more logical to allow the user to manually try a slightly different configuration if the first attempt is failing. There may be more to it than that, but I'd have to investigate.

[AdamISZ]

Taking another look at this today, I do agree there's a problem, and probably it should be explained clearly that the substance of the problem is the long delay the user experiences, in the case where tx negotiation starts successfully but does not complete, leading to a delay, in which the stallMonitor wakes up after 20 minutes by default (can be altered with maker_timeout_sec but people rarely do that). Obviously for an intended "immediate" coinjoin script (realistically it's a couple of minutes or more anyway), such a long delay inevitably will lead to the user giving up, even if, as I explained above, there is code to retry in certain cases.

Bear in mind this very long delay comes out of thinking about how the tumbler works - by waiting a long time, not just say 1 or 2 minutes as might seem reasonable if you're waiting for a counterparty to send signatures, you hope that there is at least some non-trivial change in the composition of the orderbook (if not after 20, then maybe 40 or 60).

We probably just need code to handle this case separately from how tumbler handles it. Quit earlier, don't wait as long. If a user is "manually" trying to do a coinjoin, they will at least be presented with the choice of action rather than just waiting for too long.

[AdamISZ]

Reviewing open issues again today, and I still agree that this idea makes sense. PRs welcome.