HTLC atomic swaps

A hash-time-locked contract locks funds so that the receiver can take them only by revealing a secret before a deadline, otherwise the sender gets them back.

On the side-chain:

• htlc/lock {to, token, amount, hashlock, timeout_height}: hashlock is SHA256(secret) in hex.
• htlc/claim {id, preimage}: only to, and only before timeout_height. The preimage is published in the receipt.
• htlc/refund {id}: only the locker, and only at or after timeout_height.

Funds sit in escrow at module:htlc in between. GET /v1/games/htlc?id= shows the contract's state.

These are the same semantics as the IronDivi divi-swap P2SH script on the Divi side, so one secret unlocks both sides.

A cross-chain swap

Maker A has tDIVI on Divi testnet; taker B has GOLD on the side-chain.

1. A makes a random secret s and locks the Divi-side funds in the P2SH HTLC with h = SHA256(s) and a long timeout.
2. B checks the lock and locks GOLD with htlc/lock using the same h and a shorter timeout.
3. A claims the GOLD. This reveals s on the gamechain.
4. B reads s and claims the Divi side.

divi-swapd (https://divi.cx/swap/) is the reference for the Divi side.

Why the timeouts differ

A must claim B's lock before B's timeout, and B then needs time left on A's longer lock to use s. If the timeouts were the other way round, A could claim and then wait for B's refund window to close. If anything stalls, each side refunds and nobody loses funds.