Claiming an expiring swap exploit

An integration test demonstrated this at the Rinkeby Eth chain.

Open Claims

Anyone in possession of the random HTLT key value can execute a Claim transaction on behalf of the pegged recipient with the following call:

function claim(bytes32 swapID, bytes32 randomNumber)

This allows for the following exploit:

1. Perform claim at the destination HTLT chain at x seconds before expiration.
2. Event is written at the chain log.
3. Deputy reads the event and sends a Claim at the source chain.
4. Source chain rejects Deputy's claim transaction because the HTLT timelock expired.
5. Deputy refunds the HTLT at the source chain.
6. User reversed their HTLT source chain token cost and gained at the destination.

Solution 1 (selected for this HTLT implementation):

• Deputy opens HTLT at the destination chain with a reduced time lock duration, e.g., the user initiates a new HTLT transaction with a duration of 6 hours at the Cosmos chain, and Deputy responds with a 5-hour timelock at the Ethereum chain.

Solution 2:

• Deputy does not refund expired HTLT pegs for claimed swaps at the peer chain. This is a suitable alerting opportunity for bringing operational awareness to any such exploits.
• Deputy executes a privileged claim API outside the timelock period.

Solution 3:

• Only Deputy executes claims, i.e., Solidity swap contract owner.
• Deputy exposes a public Claim Api that blocks Claim transactions x seconds before expiration.
• Deputy may execute Claim transactions anytime till expiration.