core: need a refund path that doesn't rely on dex or wallet connections

[buck54321]

This issue deals with the ability to properly refund a swap-gone-wrong. There are two parts to this issue.

1. bug: We don't load orders from the DB until we have already established a connection with the order's DEX. What happens when a DEX goes offline suddenly, causing swaps to fail, and doesn't come back? If a client is restarted before refund, they won't be able to refund until the DEX comes back online, potentially leaving the client's failed swap un-refunded beyond the lock time. This is a bug and a security hole that needs a solution.
2. Even if the DEX is connected, if the wallet is not unlocked, we can't refund. But if we generated the refund at the same time as the swap output, there would be no reason to have an unlocked wallet to refund. We'd just be broadcasting. In theory, we don't even need a wallet connection to refund, as we could devise a path to broadcast the refund to e.g. dcrdata without a wallet backend at all. But having a refund path on a locked wallet is a start, as there would be a conceivable system configuration in which a refund could happen without user input in the case of an unexpected restart.

[chappjc]

A very dumbed-down stopgap solution for refund would be to generate/sign and log the hex of the raw refund txn at the time the swap is broadcast. That way, in a pinch where even their dexc.db is toast, they can do the refund easily (without scraping for the script and using the atomicswap repo tools) like you said with dcrdata or other means of broadcast.

But that does not cover the case where maker covertly redeems, requiring taker to redeem manually too by searching out the secret key. Issue 1 with server not being reachable would break that.

To avoid actually creating unrecoverable settlement sequence errors due to transient DEX connectivity loss, I suspect the search-for-counterparty-redeem path needs a manual trigger... UI button for each match and RPC, usable when the user decides server is gone for good. This of course requires a change to Core to load active orders and their matches before DEX connect as you said.

[JoeGruffins]

I can work on this if noone else is atm.

[chappjc]

I had started on this one actually. I have a branch with some changes to order loading that facilitate this, and I'd like to see how it goes. Will try to prioritize this.

[chappjc]

A related thing I think we should be doing is creating and logging the raw refund txn when the swap transaction is created. That way its dead simple to refund as a last resort even if dexc is dead. This would of course require dexc detecting when the user did the refund (spent contract), but that can be addressed.

EDIT: eh, I repeat myself. Forgot I said just this already

[JoeGruffins]

bump

I had to update my psql databases and borked it. Not sure how to refund some swaps as I also lost the logs. On testnet so not a big deal, but seems important to get this done in case a dex went down. Would be panic mode for all users.

[chappjc]

I had to update my psql databases and borked it. Not sure how to refund some swaps as I also lost the logs. On testnet so not a big deal, but seems important to get this done in case a dex went down. Would be panic mode for all users.

So you lost the psql server databases, but which logs did you also lose?

As long as you have the client logs you have everything you need to refund (raw tx or the contract data for eth). If you lose the client logs and client db, there is no way to refund since you don't even know the contract script that you made in the first place.

[chappjc]

Oh, you mean dexc was still functional, but the order loading issue prevented it from doing the refund automatically? Yeah, I guess that needs a fix still

[chappjc]

Best I can tell is that in the year-old comment above I was talking about this branch chappjc@da813c3
I'm sure that's useless now, plus I have no clue where I had gotten with that. just a note

[JoeGruffins]

This same issue as #1583 ?

[JoeGruffins]

order loading issue prevented it from doing the refund automatically?

Yes. And also I lost my dexc logs.

Even having a new server that the clients can't trade on in place of the old one will allow the refunds to happen apparently though.

[chappjc]

Will be pushing a resolution to this today.