Temporal safety: cancel and punish timelocks, racing and finality thresholds

[zkao]

This issue opens the discussion on the temporal safety parameter. The transaction RFC presents the framework used to establish the variables:

Guesstimates for mainnet:

cancel timelock: ~ 10 + racing threshold (gives 3 hours to complete the successfull path)
punish timelock: ~ 144 (gives 24 hours to refund before punishing)

racing threshold: ~ 20 bitcoin blocks, while placing transactions at the surface of the mempool (< 0.5 MvB mempool depth. At the time of writing, the parameters above translates to ~2 USD fees on miners fees for bitcoin), and the Buy transaction has ~ 3 hours to be mined, before cancel becoming valid.

cancel timelock ~ racing threshold
cancel timelock ~ 1/fee

finality thresholds: bitcoin lock >= 2 blocks and monero lock >= 10 blocks. That takes on average > 20 min to lock bitcoin, and add to that 20 min to lock monero. So on average swaps paying high fees take 40 min for Bob to receive his monero, and 20 min for Alice to receive her bitcoin.

Note that as soon as Alice buy transaction shows up on the mempool, Bob has access to the monero secret keys he needs. So if parameters aren't chosen correctly, even if the transaction never gets mined on the bitcoin blockchain, Bob will still get the monero, and might as well get his bitcoin back, if he cancels and refunds.

Nontheless, if cancel is set too high, Alice might watch for price volatility and decided to exercise the option to buy the bitcoin (free option problem is enhanced) if cancel is too low, Bob might try to race buy with cancel, and try to get both the bitcoin and monero.

free-option magnitude ~ cancel timelock

For saving on fees, cancel time lock should be larger. That is, Alice has 10 blocks after the Lock was mined to publish her buy transaction. After 10 blocks we assume cancel might race buy. Cancel becomes valid after Lock has 10 confirmations.

Real-time fees must be compatible with such times