Atomic swaps are a method of exchanging one asset for another, such as two cryptocurrencies, even if they exist on distinct blockchains. The idea is to do this in a trustless way, avoiding counterparty risk, so that the swap either goes ahead and both parties receive what was agreed, or the whole thing is cancelled. It should not be possible for one ‘leg’ of the exchange to go through on its own without the corresponding payment. So, we can treat the entire exchange as a single trade which either goes through or not. As separate blockchains exist in isolation, and cannot directly communicate, atomic swaps are a useful cross-chain solution. They help to build a more interoperable ecosystem of interacting blockchains. Furthermore, atomic swaps can also be used with off-chain payments such as on the lightning network, connecting these with on-chain transactions.
Consider the scenario: Alice owns bitcoin, which she wants to use to purchase ether from Bob. The exchange rate (BTCETH) at the time is about 13. So, they agree to a swap where she sends one bitcoin to Bob and, in return, he sends 13 ether to Alice’s Ethereum account address.
This is fine in theory but, before sending her payment transaction to the Bitcoin blockchain, she has second thoughts. What happens if Bob does not submit his corresponding transaction? In that case, she will have sent him the bitcoin with nothing in return. Can he really be trusted? So, she asks Bob to submit his transaction first. However, Bob is also not really sure that he can trust Alice. If he submits his Ethereum transaction before Alice’s payment is confirmed, how can he be sure that he will be paid? To be safe, both parties in this transaction want the other to confirm their payment first. Consequently, they do not go ahead with the exchange.
What can be done to resolve the issue of trust and counterparty risk? This is not something specific to cryptocurrencies. Whenever two parties want to exchange any items of value, there is the possibility that one of them will not follow through with their side of the agreement. Here are three possible solutions.
- Resort to law courts. Draw up a contract in advance, signed by both parties and legally enforceable. Then, if Bob did not deliver the ether in return for Alice’s payment, she could take him to court to recover either her payment or the ether that she was promised, plus costs. This is a rather time consuming and expensive approach, and may not even be successful if Bob cannot be contacted or resides in a location outside the jurisdiction of the court. It is really not workable for frequent low-value peer-to-peer transactions done online.
- Involve a trusted intermediary. This requires a third party, who we will call Carol, and who needs to be trusted by both Alice and Bob. She acts as a custodian for the payments. Alice sends her bitcoin to Carol and, similarly, Bob sends his ether to her. Once she has received both payments, she passes on the bitcoin to Bob and the ether to Alice, so that the exchange is complete. If Bob did not send his payment within a pre-agreed time period, Alice can simply ask Carol to return return her bitcoin and the exchange is cancelled.
Figure 1: Carol acts as an intermediary The blockchain contracts and transfers for this solution are outlined in figure 1 above. Rather than directly facing each other, Alice and Bob both face Carol. This is a tri-party agreement. If all goes well, we end up with the bitcoin in a contract controlled by Bob, and the ether in one controlled by Alice, shown in green. If either party defaults by failing to make their payment on time, Carol returns the opposing payment to the sender, shown in red.
This method will involve some costs, since Carol will expect to be paid for her services. It also does not entirely remove the issue of trust but, instead, replaces it with the requirement to trust the third party, Carol. This is effectively what we are doing when we make transactions on a centralized exchange like Coinbase or Binance. We need to place trust in the exchange itself that they will return to us the correct amount of assets that we are due, after fees have been taken. We do not place trust in the other users of the exchange who are on the opposite side of any trades that we make. It is not ideal if we are wanting to make peer-to-peer swaps directly with the other party.
- Combine the two payments into a single transaction. This would be straightforward if the two assets being exchanged live on the same blockchain. Suppose, for example, that Alice was paying wrapped bitcoin (WBTC). This exists as an ERC-20 token on the Ethereum blockchain, and is supposed to be backed by actual bitcoin held by some custodians. Then, rather than creating separate transactions for the two legs of the swap, a single transaction could be created that simultaneously transfers WBTC to Bob and ether to Alice. This transaction is either signed by both parties and added to the Ethereum chain, or the exchange does not take place at all. Since they are combined, it is not possible for only one leg to be confirmed without the other.
If the assets exist on different blockchains, then the transactions representing each leg necessarily live on their respective chains, so cannot be combined. However, it is still possible to link them via a secret code which is revealed by the transactions of one leg. This can then be used to unlock the transactions in the other leg. Effectively, this transfers information across from one chain to the other. The two legs are then linked in such a way as to remove the counterparty risk and trust issues. I explain these atomic swaps in this post.
Hash Time Locked Contracts
Atomic swaps, whereby Alice and Bob can exchange one asset for another, can be constructed with the use of Hash Time Locked Contracts (HTLCs). In some ways, this is similar to the use of an intermediary to remove trust issues, as described in solution 2 above. The transactions are very similar to those shown in figure 1 except, now, the intermediary Carol is not needed. The contracts which she controls are instead replaced by HTLCs, which are controlled cooperatively by Alice and Bob themselves. This is as in figure 2 below, which I will explain in more detail in a moment.
The first step is for both Alice and Bob to make their payments into intermediate addresses, or contracts. In order to lock these contracts until both parties have paid in, we need an additional constraint restricting how the assets can be withdrawn. The idea is to use a secret code (or, key) which needs to be chosen by one of the two parties. By exposing this secret code, the contracts can be unlocked so that each party receives the agreed amount of the asset.
To start, Alice chooses a secret code S to lock the intermediate contracts. This should be a random binary string with sufficiently many digits that it is infeasible for any other party to guess. She then computes its hash H = h(S). By the properties of cryptographic hash functions (e.g., SHA-256), knowing the value of H does not help to find the secret S, other than by an infeasible brute force trial-and-error. She can then send H to Bob without revealing the secret code S.
Alice then creates a transaction on the Bitcoin blockchain which can only be unlocked by Bob with his private key. However, an additional constraint is added, so that Bob can only extract the bitcoin if he also provides the secret value S. This is done in the transaction output script by checking that any spending transaction not only provides a valid signature for Bob’s public key, but also a value S whose hash is equal to H. This script only needs to contain the hash value H, and not the secret itself. So, by doing this, Alice keeps the secret code safe while using it to encumber the contract. This is known as a hashlock. In the same way, Bob also creates a transaction on the Ethereum blockchain sending his ether to a hashlock contract, which can only be unlocked by Alice signing with her private key in conjunction with the secret code.
For the second step, Alice uses her secret code and private key to withdraw the ether from Bob’s hashlock contract in the Ethereum blockchain. This is the transaction paying into Alice’s address displayed in green on the left of figure 2.
Here comes the clever point, on which atomic swaps rely for their security. Blockchains are publicly visible. So, any transaction which Alice uses to withdraw the ether from Bob’s contract will also contain the secret code S. Since Bob can see this, he can read the value of S, and hence withdraw the bitcoin from Alice’s timelocked contract. This is the transaction paying into Bob’s address shown in green on the right of figure 2. Sure, Alice can directly send the secret to Bob so that he can receive the bitcoin. The important point is that he does not need to rely on her to do this. It is not possible for Alice to withdraw the ether without also revealing the secret value which Bob needs to obtain the bitcoin.
There is still a big security issue with the procedure outlined so far. After Alice pays into the hashlock contract, what happens if Bob becomes unresponsive and never pays the ether into the corresponding one? This means that he will not be able to obtain the bitcoin but, the problem is, neither will Alice. Instead, it will be forever stuck in a contract requiring both Bob’s private key and the hashlock to be accessed. Similarly, after Bob pays into his hashlock contract, if Alice never reveals her secret then she will not be able to access the ether, but neither will Bob.
These issues can be resolved by having the intermediate contracts return the coins to the sender after some period of time. For the one which Alice pays the bitcoin into, she adds an alternative spend method where she is able to spend the coins herself, but only after a specified time. Similarly, the contract into which Bob pays has an alternative spend method by which he can recover the ether after a given time. These alternative spend methods are known as timelocks, and are represented in figure 2 by a small clock following the name of the individual who is able to spend from the contract after the lock expires.
Contracts like these which have two spend methods, one with a hashlock and the other with a timelock, are the HTLCs mentioned above. The idea is very similar to the use of an intermediary, Carol, described in solution 2 higher up in this post. There, Carol would return payments to the sender if the other party defaulted on their payment. HTLCs allow us to automate this process and remove Carol from the picture.
Putting together the ideas explained above gives the following steps.
- Alice randomly selects a secret code S and computes its hash H = h(S).
- Alice pays the bitcoin into an HTLC contract with two spend methods:
- Bob can spend by providing a signature along with the code with hash equal to H.
- Alice can spend by signing, after time TA.
- Bob pays the ether into an HTLC contract with two spend methods:
- Alice can spend by providing a signature along with the code with hash equal to H.
- Bob can spend by signing, after time TB.
- Alice withdraws the ether from Bob’s HTLC by providing a signature along with the secret code S.
- Bob withdraws the bitcoin from Alice’s HTLC by providing a signature along with the secret code S. He is able to read the value of S from Alice’s transaction sent to the Ethereum blockchain in the previous step.
This describes the atomic swap assuming that there are no problems, and that it successfully completes. They do need to wait after each of steps 2 and 3 for the HTLC transactions to be confirmed on their respective blockchains before moving on to the next step. After it is initiated by Alice in step 2, there are only two sources of counterparty risk, causing the swap to be cancelled.
- Bob does not pay the ether into the HTLC contract in step 3. If this is not done by the time TA that the first timelock expires, Alice can recover her bitcoin.
- Alice does not submit the transaction in step 4 or otherwise reveal the secret code to Bob. If this is not done by time TB that the second timelock expires, Bob can recover his ether.
The constraint on the timelocks is that TA must be sufficiently greater than TB to give Bob plenty of time to withdraw the bitcoin payment and for his final transaction to be confirmed, without risking the timelock running out and Alice taking it back.
Some History
The generally accepted history of atomic swaps is that they were first described by Sergio Demian Lerner in 2012 by a post to the bitcointalk forum. These ideas were fleshed out in more detail on the same forum a year later by Tier Nolan. It was not until 2017 that the first atomic swap was performed, exchanging Litecoin for the Decred cryptocurrency. An atomic swap between Litecoin and Bitcoin was performed a few days later by Charlie Lee.
Interestingly though, the underlying idea was already mentioned very briefly by Satoshi Nakamoto back in December 2010 in the bitcointalk forum thread BitDNS and Generalizing Bitcoin. This was while discussing the idea of using a separate blockchain for the BitDNS project, which eventually became Namecoin. Even if they were running on different blockchains, as Satoshi noted, it would still be possible to set up risk free trades between them. Note, in particular, the final paragraph of Satoshi’s post transcribed below:
Piling every proof-of-work quorum system in the world into one dataset doesn’t scale.
Bitcoin and BitDNS can be used separately. Users shouldn’t have to download all of both to use one or the other. BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.
The networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it’s easy for lots of users and small devices.
Fears about securely buying domains with Bitcoins are a red herring. It’s easy to trade Bitcoins for other non-repudiable commodities.
If you’re still worried about it, it’s cryptographically possible to make a risk free trade. The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer’s signature triggers the release of both. The second signer can’t release one without releasing the other.
This is lacking in detail, and does not describe HTLC contracts, as we would expect for a brief comment within a larger discussion. However, it does explain that for one party to retrieve their coins by signing the transaction, they necessarily provide some secret information allowing the counterparty to also retrieve their payment.
Zero Knowledge 