ARRR swaps fail due to timeout if slow block production / more than 1 swap started in parallel

[cipig]

here are the swap files from maker and taker from such a swap 23c18197-5c4f-4859-bc2a-414f0a049456.json.maker.txt 23c18197-5c4f-4859-bc2a-414f0a049456.json.taker.txt

taker failed with

         "event" : {
            "data" : {
               "error" : "taker_swap:1084] Error waiting for 'maker-payment' data: lp_swap:276] Timeout (691 > 690)"
            },
            "type" : "MakerPaymentValidateFailed"
         },
         "timestamp" : 1670796751767

because maker took much too long to send makerpayment, more than 23 minutes... so more than 690s, that's why the swap failed for more than 23 minutes maker just showed [swap uuid=23c18197-5c4f-4859-bc2a-414f0a049456] Taker fee validated... without proceeding to Maker payment:

| (0:16) [swap uuid=23c18197-5c4f-4859-bc2a-414f0a049456] Negotiated...
11 22:01:00, maker_swap:704] INFO Taker fee tx 169db752aac7113d00c79ae24d3e801b89f1058349d42e64df14643cdfbf4831
| (0:24) [swap uuid=23c18197-5c4f-4859-bc2a-414f0a049456] Taker fee validated...
...
...
| (23:14) [swap uuid=23c18197-5c4f-4859-bc2a-414f0a049456] Taker fee validated...
11 22:24:12, maker_swap:808] INFO Maker payment tx 859cc25796dd1e4338d8b8dc4e06599595e879cf2df1c401339c60490aa718c7
| (23:29) [swap uuid=23c18197-5c4f-4859-bc2a-414f0a049456] Maker payment sent...

there was another swap with ARRR on that node (644ce894-d59b-4e1f-b4c1-b71d28959e1a), started couple seconds before 23c18197-5c4f-4859-bc2a-414f0a049456 that sent makerpayment much earlier, but still almost 4 minutes after swap started... that one completed fine

| (3:56) [swap uuid=644ce894-d59b-4e1f-b4c1-b71d28959e1a] Taker fee validated...
| (3:07) [swap uuid=23c18197-5c4f-4859-bc2a-414f0a049456] Taker fee validated...
11 22:03:54, maker_swap:808] INFO Maker payment tx 39f1d7efa45f467ed5ae65933ae022ff4cefeb422fa36ea10dc1fa25684cfe8a

a third swap, started after the 2 from above (but still before the others completed) failed too with same error and same reason (maker took more then 690s to send makerpayment after takerfee)

the 2 failed swaps are the same as in https://github.com/KomodoPlatform/atomicDEX-API/issues/1570

could it be related to block production in ARRR? saw this 21 minute gap earlier i actually thought that mm2 constructs txes even with unconfirmed inputs... is it different in ARRR?

[himu007]

yes, i was doing these parallel swaps with your node and there was huge gaps in blocks at the exact time.

we can't use unconfirmed inputs in ARRR. every zutxo needs to be confirmed.

So, no parallel swaps for ARRR, unless we have many zutxos in a zaddr or mm2 timeout for ARRR needs to be increased.

[artemii235]

It was an unlucky coincidence that these concurrent swaps happened during big gaps between blocks. But anyway, as @himu007 mentioned, zutxos must be confirmed before spending, so the number of concurrent ARRR swaps is very limited.

unless we have many zutxos in a zaddr

This means that we will require to implement splitting, which might be tricky, as we can't really predict the required trading amount (maker order can be partially matched). Having many small zutxos will also be a problem, because transaction generation and signing may take a significant time in case of large number of inputs.

mm2 timeout for ARRR needs to be increased.

Increasing the timeout is the simplest solution and might help to cover some of such situations.

Would be also nice to avoid these gaps between blocks as much as possible 🙂

[cipig]

Would be also nice to avoid these gaps between blocks as much as possible

Yes, that would be nice. This is how mining usually looks like in ARRR:

7 blocks in one minute, then gaps of several minutes it's coming from luxor.tech, a profit switch mining pool: https://miningpoolstats.stream/piratechain they also mine nearly 90% of all blocks... but like that more stable miners and less profit switchers are needed

[himu007]

Increasing the timeout is the simplest solution and might help to cover some of such situations.

@artemii235 This is a good idea. Also, is it possible to add a retry as well on top of increasing the timeout?

[smk762]

Today again we've seen high hash then slow blocks on ARRR, resulting in timeout fails. Is extending the timeout as simple as increasing "ave_blocktime" in coins repo? I've also seen in testing that generating ARRR transactions can take a bit longer than the average coin, so I suggest doubling the timeout to cover this too.