Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

swap: stuck due to low fee (potential solutions) #3135

Open
norwnd opened this issue Jan 2, 2025 · 3 comments
Open

swap: stuck due to low fee (potential solutions) #3135

norwnd opened this issue Jan 2, 2025 · 3 comments

Comments

@norwnd
Copy link
Contributor

norwnd commented Jan 2, 2025

It is possible for Swap transaction to get stuck for 8+ hours (and/or never get mined),

I'm not sure what happens in case such Swap transaction does get mined eventually - I'm assuming Bison wallet will realize it needs to refund it ASAP and will send a Refund transaction (for Maker that's safe behavior, for Taker that's safe until 20h into the Match),

but what happens in case such Swap transaction never gets mined is - corresponding Match ends up in a hanging state where "it thinks Swap happened" (even thought it actually didn't) and "it thinks Refund is coming" (even though Bison wallet cannot possibly refund it since there is nothing to refund); all the while wallet also thinks Swap transaction is pending in mempool (which is technically correct but might be confusing to a User, so it's probably best to clean it up after Match state is resolved one way or another), here is how such stuck Match looks like:

image

I think there are at least two different ways this can be addressed:

  1. (optimistic) just do nothing until certain timestamp in the future, and then simply clean-up Match and wallet Swap transaction pending in mempool; that's simple but could be naive in case Swap transaction does get mined eventually against all the odds
  2. (proper) or instead issue a so-called Cancel transaction spending Swap funding coin forcefully to make sure Swap transaction never comes back to life guaranteed (perhaps only after network fees have dropped and are reasonably low)

Another note, #3131 also probably depends on the resolution of this issue since Swapping balance (under Locked section) keeps showing funds reserved by stuck Swap transaction even after I've sent another Polygon transaction with the same nonce that got mined (effectively replacing/invalidating that Swap transaction completely) - which is probably due to corresponding Match still expecting Refund that will never happen.

Another aspect of this issue - it seems bumping fee for Swap transaction for EVM-based assets (through manual user-action request) isn't working correctly because if Swap tx1 was replaced by tx2 (with higher fee) Match won't know about it and we keep trying to convince server tx1 is the Swap transaction to look for (we do refund Swap tx2 successfully in that case though, that's good 👍 )

it seems Redeems/Refunds would suffer from exactly the same issue of Match being unaware of fee-bumped transaction - but the code handle this for Redeems/Refunds exists (see code around ConfirmTransaction in https://github.com/decred/dcrdex/pull/3082/files) ... and that probably means we need

  • to have similar functionality for Swaps
  • it's a bit unfortunate that for EVM-based transactions to bump fees "manual user action" is required (while for BTC or DCR it's handled automatically), perhaps it would be best to automate this for EVM-based assets as well ("manual user action" would need to be disabled for every transaction type except for Sends I guess to prevent interference with automated fee-bump functionality) - this is especially desirable for Swap transactions where user simply might not have enough time to react if he doesn't monitor all his open trades 24/7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@norwnd and others