security: taker can lock maker funds without getting his funds locked

[moshababo]

Scenario:

• taker is paying the maker the 1st leg of the swap.
• maker receives the taker HTLC, and is paying the taker the 2nd leg of the swap.
• taker receives the maker HTLC, but is shutting down instead of settling the invoice and releasing the hash preimage.

Outcome: maker gets swap timeout, and is cancelling the taker invoice (1st leg) and so releasing the taker funds, while the taker invoice (2nd leg) is not cancelled and so the maker funds are locked until he will force-close the channel on-chain.

[sangaman]

so the maker funds are locked until he will force-close the channel on-chain.

Unless I'm mistaken I believe the funds are only locked until the HTLC expires. I don't think force-closing the channel is necessary unless the other side of the channel is uncooperative, but if they're uncooperative then all funds on the channel are locked until force-close no matter what since that's how LN is designed.

[ghost]

Unless I'm mistaken I believe the funds are only locked until the HTLC expires

That was my initial response/understanding of the issue as well.

[moshababo]

Closing a channel with a pending HTLC cooperatively doesn't seems to work, although both parties remain connected and responsive.
Here's the test: https://github.com/ExchangeUnion/xud/pull/1047/files#diff-daf6bab84d805fdac657e724cbf96c3cR287

Let me know if i'm missing something.

[kilrau]

Todo: documentation on how to resolve via force close

[moshababo]

Update: test case was already fixed so that maker channel will get closed after HTLC expiration. It just required more waiting steps before the funds could return to wallet balance (see testTakerShutdownAfter2ndHTLC implementation).

We should keep this issue open only if we want to disable the maker cancelling the taker invoice, and so allowing his funds to get easily released, instead of punishing him.

[sangaman]

I'm thinking we should leave this issue alone for now (not modifying our cancel logic for now) on the grounds that we will ban a peer eventually whose swaps timeout repeatedly. I believe it's also possible that the maker's HTLC can get held up due to an unresponsive intermediary, so we may be punishing an "innocent" taker. We can revisit this topic if it becomes an issue later on.