fix warning behaviour around monero-rpc failing to fetch transactions

[icy-ux]

potential fix for #1061

don't warn the user that monero-wallet-rpc has failed to fetch a
transaction until it's happened several times.

monero-wallet-rpc may legitimately fail the first time we make a request

[ikmckenz]

I think this probably fixes the erroneous error messages caused by fetching the tx too soon after sending. It seems that the check_interval for Mainnet is 2 minutes, so this ends up waiting a total of 10 minutes for the tx before printing the warning message? I think this is probably too long, especially since this can be time sensitive to avoid punishment. Perhaps just one retry before the warning message would be better?

[icy-ux]

@ikmckenz what is the actual punishment timeout in this case? I thought punishment would only happen after many hours or some days.

[ikmckenz]

I believe it is 72 bitcoin blocks (approx 12 hours). That feels like it should be plenty of time, but it seems there are many issues in the queue related to users getting punished and not understanding why or what they were supposed to do. I guess my follow up question is: In what scenario could this check fail after the first retry (a full 2 mins after submitting), but succeed on the 5th retry (10 mins after submitting)? I don't really see how that could happen, I would think that if the first retry fails a full 2 mins after submitting, it will continue to fail, and thus the extra 8 minutes of waiting is not helping but just taking away a users time until punishment.

From my reading through all the messages in #1061, it looks like this warning message primarily (only?) happens on the asb side these days, not the swap side. If that's the case I guess the 10 minute timeout isn't as much of an issue, but in the past the issue on the swap side has been version mismatch causing decoding errors, and that is definitely an example where extra retries after the first 2 minute check would do nothing, and take away valuable time before punishment. Hopefully integration tests have been improved since then to prevent an issue like that from happening again.

@delta1 what do you think about 1 retry vs 5, am I way off here?

Separately from this discussion, it seems a lack of documentation around the punish action and timeouts and what a user has to do to prevent this is leading to users getting punished, perhaps better documentation around that is needed.

[icy-ux]

On Sat, May 18, 2024 at 11:04:01AM -0700, Ian McKenzie wrote: I believe it is [72 bitcoin blocks (approx 12 hours)](https://github.com/comit-network/xmr-btc-swap/blob/master/swap/src/env.rs#L54). That feels like it should be plenty of time, but it seems there are many issues in the queue related to users getting punished and not understanding why or what they were supposed to do.

I don't think that's related to this issue, since these changes haven't been implemented yet. There were some discussions in the Matrix chat about bugs or problems on the `asb` side causing swaps to fail in nasty ways, I don't remember the details. Those issues are much more likely to be responsible for users getting punished.

I guess my follow up question is: In what scenario could this check fail after the first retry (a full 2 mins after submitting), but succeed on the 5th retry (10 mins after submitting)? I don't really see how that could happen, I would think that if the first retry fails a full 2 mins after submitting, it will continue to fail, and thus the extra 8 minutes of waiting is not helping but just taking away a users time until punishment.

If the user has 12 hours until punishment, 8 minutes either way are a drop in the ocean. I don't recall exactly why I chose to allow up to 5 retries -- it has been quite a while since I did this. The timing and count would have been chosen based on my observation of the situation in practice. I think `monerod` can take quite a while to sync blocks in some situations (like the server being overloaded).

Separately from this discussion, it seems a lack of documentation around the punish action and timeouts and what a user has to do to prevent this is leading to users getting punished, perhaps better documentation around that is needed.

Better documentation is always a good idea!