Breaking swaps tests

[kilrau]

This issue collects scenarios for tests which intend to break the swap protocol:

1. swap partners a) go offline or b) become unresponsive (socket open, but stalling) in various states of the swap:

• 1.1 taker goes offline/becomes unresponsive after maker confirms quantity in swapAccepted
• 1.2 maker goes offline/becomes unresponsive after maker confirms quantity in swapAccepted
• 1.3 taker goes offline/becomes unresponsive after taker set up first HTLC to the maker
• 1.4 maker goes offline/becomes unresponsive after taker set up first HTLC to the maker (to be fixed: security: maker can lock taker funds #1048)
• 1.5 taker goes offline/becomes unresponsive after maker set up second HTLC to taker (before settleinvoice) (to be fixed: security: taker can lock maker funds without getting his funds locked #1049)
• 1.6 maker goes offline/becomes unresponsive after maker set up second HTLC to taker (before settleinvoice)
• 1.7 taker goes offline/becomes unresponsive after releasing the preimage (settleinvoice) (maker doesn't get swapCompleted message)
• 1.8 maker goes offline/becomes unresponsive after the taker released the preimage (maker doesn't get swapCompleted message) (to be fixed: security: maker can lose funds due to a crash #1050)
• 1.9 taker goes offline/becomes unresponsive after the maker released preimage for first payment

2. swap partners a) force-close or b) cooperatively close channels in various states of the swap:

• taker force-closes/cooperatively closes channel after maker confirms quantity in swapResponse
• maker force-closes/cooperatively closes channel after maker confirms quantity in swapResponse
• taker force-closes/cooperatively closes channel after taker set up first HTLC to the maker
• maker force-closes/cooperatively closes channel after taker set up first HTLC to the maker
• taker force-closes/cooperatively closes channel after maker set up second HTLC to taker (before settleinvoice)
• maker force-closes/cooperatively closes channel after maker set up second HTLC to taker (before settleinvoice)
• taker force-closes/cooperatively closes channel after preimage release (maker doesn't get swapCompleted message)
• maker force-closes/cooperatively closes channel after preimage release (maker doesn't get swapCompleted message)
• taker force-closes/cooperatively closes channel after the maker released preimage for first payment

3. Change currency ticker/token address (after #910 is merged)

• taker changes currency in p2p messages after maker confirms quantity in swapResponse
• taker changes currency (create htlc on different payment channel) after maker confirms quantity in swapResponse.
• taker changes currency (create htlc on testnet payment channel of same currency) after maker confirms quantity in swapResponse.
• maker changes currency in p2p messages after maker confirms quantity in swapResponse
• maker changes currency in p2p messages after taker set up first HTLC to the maker
• maker changes currency (create htlc on different payment channel) after taker set up first HTLC to the maker
• maker changes currency (create htlc on testnet payment channel of same currency) after taker set up first HTLC to the maker
• taker changes currency in p2p messages after taker set up first HTLC to the maker
• taker changes currency in p2p messages after maker set up second HTLC to the maker
• maker changes currency in p2p messages after maker set up second HTLC to the maker
• taker changes currency in p2p message after preimage release (in swapCompleted message)

4. TBD: send more/less

5. TBD: change amounts in xud p2p communication

6. TBD: testnet/mainnet mix

7. TBD: send/receive orders over channel/payment size limit

8. TBD: alter cltv delta to sth short, try to trick trading partner to accept it

9. TBD: other misc p2p message alteration

10. TBD: change xud nodePubKey after successful connection on p2p layer

**All tests are done for all supported pairs in both directions:

• ltc/btc buy/sell
• weth/btc buy/sell
• btc/dai buy/sell
• ltc/dai buy/sell

Since some of these intend to exploit delays, tests need to mine blocks quick to simulate the waiting time and check if funds were successfully returned. The general idea is to create different xud versions for the scenarios.

[kilrau]

@moshababo as per call the idea is to integrate this into the simulation tests. Thinks to consider by @moshababo :

• bloat the repo with many files for each xud version, so we might want to keep it in a separate place
• We should also focus on load/stress scenarios as well, with a legit xud client (in addition to adversary lnd/raiden level behavior)
• Keep in mind that integrating raiden into the tests is a big task (need to wrap both geth and raiden, something we didn’t need to do with btcd/ltcd/lnd, because they provided the integration framework).

[moshababo]

Known issues: #1048, #1049, #1050

[kilrau]

Known CLTV issues: #1043

[kilrau]

First step towards a graceful handling of above scenarios: #1079

[kilrau]

I think we can close here once #1204 is merged and continue tracking there.

[sangaman]

I think we can close here once #1204 is merged and continue tracking there.

Agreed, I'll wrap up #1204 today and have it close this PR when merged.