LightSwap: An Atomic Swap Does Not Require Timeouts at both Blockchains

Abstract

Security and privacy issues with centralized exchange services have motivated the design of atomic swap protocols for decentralized trading across currencies. These protocols follow a standard blueprint similar to the 2-phase commit in databases: (i) both users first lock their coins under a certain (cryptographic) condition and a timeout; (ii-a) the coins are swapped if the condition is fulfilled; or (ii-b) coins are released after the timeout. The quest for these protocols is to minimize the requirements from the scripting language supported by the swapped coins, thereby supporting a larger range of cryptocurrencies. The recently proposed universal atomic swap protocol [IEEE S &P’22] demonstrates how to swap coins whose scripting language only supports the verification of a digital signature on a transaction. However, the timeout functionality is cryptographically simulated with verifiable timelock puzzles, a computationally expensive primitive that hinders its use in battery-constrained devices such as mobile phones. In this state of affairs, we question whether the 2-phase commit paradigm is necessary for atomic swaps in the first place. In other words, is it possible to design a secure atomic swap protocol where the timeout is not used by (at least one of the two) users?

In this work, we present LightSwap, the first secure atomic swap protocol that does not require the timeout functionality (not even in the form of a cryptographic puzzle) by one of the two users. LightSwap is thus better suited for scenarios where a user, running an instance of LightSwap on her mobile phone, wants to exchange coins with an online exchange service running an instance of LightSwap on a computer. We show how LightSwap can be used to swap Bitcoin and Monero, an interesting use case since Monero does not provide any scripting functionality support other than linkable ring signature verification.

A full version of our paper is available in [2].

A Detailed Comparison with Gugger Protocol

Gugger proposed a protocol for swapping B’s bitcoins for A’s monero without using timelocks at the Monero side [16]. A locks her monero in an address, whose one half of the private spend key is with A and other half with B. On the other hand, B locks bitcoin in a 2-of-2 multi-sig address having two outputs, one is redeemed and one is for refunding. The redeem script uses a hashlock where the preimage of the hash must be used for claiming Bitcoins. Initially B locks bitcoin and upon confirmation, A locks her monero. After A has verified that B has locked bitcoin, she sends the preimage of the hash defined in the redeem script. Using it, B publishes the redeem transaction and releases his part of the private spend key to A. The latter uses it to construct the private spend key and claim monero. A is at risk of losing her deposit forever if B refuses to collaborate while refunding. There is no way A can refund her coins without B’s secret. The schematic diagram of the protocol is shown in Fig. 3.

To address these problems, we propose a protocol that allows A to refund instead of depending on B. With this guarantee, she can always move first by locking XMR before B locks BTC. We use the adaptor ring signature for the refund transaction of Monero. But making this minor change in [16] won’t help since providing freedom to A puts B at risk of losing money. It is quite possible that A publishes the refund transaction first and then claims bitcoins. To prevent such a situation, A will be allowed to claim bitcoins only after B has redeemed monero. Thus once A publishes the redeem transaction, the money cannot be spent immediately. A contest period is added before she can claim bitcoins.