Since the activation of segwit, there’s been a renewed excitement around the idea of cross-chain atomic swaps. Up until a few days ago, some old school swaps were set up to trade 1000 Bitcoin, approximately $8M, for a now-defunct altcoin, and a handful of atomic swaps have been successfully performed involving notable segwit-enabled chains. Today, Lightning Labs is excited to announce that we have successfully tested the first Lightning cross-chain atomic swap between the Bitcoin and Litecoin testnets!

So what is a swap? A cross-chain atomic swap is used to exchange funds between two participants, say Alice and Bob, whose assets reside on separate blockchains. This is achieved by having Alice and Bob execute a protocol that guarantees the atomicity of the transfer.

Here, the atomicity of a swap refers to the constraint that the protocol should only have two outcomes, either Alice and Bob successfully exchange assets, or nothing happens. This property is crucial, as it ensures that neither party can cheat the other, and offers a method of swapping cryptocurrencies without a trusted third-party.

The ability to swap currencies instantly using Lightning offers a number of benefits, such as instant settlement, improved privacy, and low trading fees. We are particularly excited by this technology, as it provides a brief glimpse at the future of non-custodial, Lightning-based exchange infrastructures.

On-Chain Swaps

We’ll start with a diagram of a simple on-chain swap protocol (the original description can be found here). As a disclaimer, more complex on-chain protocols exist, but we will focus on this one to grok the core principles.

The image above depicts the dependencies of transactions that are generated in order to facilitate the swap. Note that the sequence numbers indicate the order in which transactions are signed, but not necessarily the order in which they are created. Following the arrows in the upward direction represents both the order that the transactions would be crafted and (potentially) spent on their respective chains. Solid arrows are used to indicate the paths taken in the event of a successful swap. In order to tie this in later, I’ve taken the liberty of borrowing some Lightning terminology to describe the different transaction types.

At the start of the protocol, Alice has 1 BTC in her funding transaction and Bob has 10 LTC in his. If all goes well, the protocol will leave Alice with 10 LTC in her claim transaction (6), and Bob with 1 BTC in his (7).

The atomic swap protocol proceeds through two phases, which we’ll refer to as the setup phase (1–5) and claim phase (6–7). The three protocols we discuss today will all share these seven steps. At any point before entering the claim phase, either party can abort, and each will be refunded with the amount in their original funding transaction. However, once the claim phase has been entered, both Alice and Bob are irreversibly and immediately free to take the coins from other chain, but not their original coins.

Setup Phase

The setup phase is responsible for installing all of the safety nets that protect both Alice and Bob during the transfer. As the initiator, Alice begins by generating a random 32-byte preimage, x, keeping it secret for now. We will use H(x) to denote the hash of the preimage, using a hash function such as SHA256.

She then crafts a special commit transaction containing H(x), which acts as a temporary account that will only release her 1 BTC under one of two conditions: either Bob is able to present x, or Alice waits 48 hours for a refund. This means, so long as Alice provides Bob with x before the deadline, he will be able to claim his 1 BTC. Alice’s refund transaction is signed by both parties before the commitment transaction, ensuring she doesn’t move her BTC into an account she can’t withdraw from. Without this, Bob could decide not to complete the multisig, and hold Alice’s money hostage.

We then set up Bob’s safety nets for his 10 LTC, by creating a commitment transaction containing the same H(x), and signing his refund transaction using the same ordering as for Alice. The primary distinction is that Bob’s refund timeout is only 24 hours, instead of 48. This interlocking is crucial to the safety of the protocol, as we shall see.

The setup phase is complete after each commitment transaction has been confirmed on their respective blockchains.

Claim Phase

At this point, Alice is still the only participant who knows x. With this, she is free to claim the 10 LTC in Bob’s commitment transaction anytime before the 24 hour deadline. On the other hand, Bob does not know x, but has 48 hours to claim his 1 BTC. By design, both commitment transactions are locked with the same H(x), so Alice cannot claim her LTC without also revealing x to Bob.

The only thing Alice can do to receive her 10 LTC is to broadcast her claim transaction. If she does nothing, then both parties will be refunded and we’re back to square one. The only question left is when does she broadcast (and reveal x)?

Remember that Bob’s refund will happen after only 24 hours. If Alice were to reveal x after that time, Bob will have taken his refund in LTC, and can now claim the BTC from Alice’s commitment transaction! Thus, if Alice wants her LTC, she is forced to broadcast before the first 24 hours is up. This, in turn, leaves Bob an ample amount of time to claim the 1 BTC from Alice using x, and each goes home having successfully swapped BTC for LTC.

So, How Does This Relate to Lightning?

The result of the on-chain swap protocol is determined at the moment Alice reveals x to Bob. The claim phase may continue to play out after sending x, but Alice and Bob are locked into completing the swap, or they risk ending up with nothing. Using this preimage-based approach to transacting, the actual latency required to send an atomic payment reduces from an hour or more on chain, to however fast Alice can send 32 bytes to Bob.

I know what you’re thinking. Wouldn’t it be awesome if people were already building a high-speed, decentralized network for anonymously sending payment preimages? 😏

Under the hood, the Lightning Network uses a special type of payment called a Hashed Time-Locked Contract (HTLC). HTLCs are structurally very similar to the contracts used in our previous example—they use timelocked refunds for safety, and atomically move funds by revealing preimages. In fact, at the scripting level, an HTLC is differentiated only by one additional clause, which can be used to indefinitely extend the life of a channel in the cooperative case.

For the sake of simplicity, we will ignore how this last clause is used, and only consider a single payment in describing Lightning payments and swaps. Remember that in practice, we wouldn’t typically broadcast the outcome of a Lightning payment to chain, but it can helpful to think about this scenario to visualize the transaction dependencies. Either party has the ability to “cash out” at any time, by broadcasting their commitment transaction to chain. The software should readily detect this event by then claiming any funds locked under a known x, or waiting to claim refunds after the timeouts expire.

Simplified Lightning Payment

The diagram above depicts a simplified schematic of a single Lightning payment from Alice to Carol, through Bob. The route consists of two Bitcoin channels and atomically sends the payment over the Alice-Bob channel, followed by the Bob-Carol channel. If v is the amount that is being paid to Carol, a successful payment will leave Alice v Bitcoin poorer, Bob will net zero, and Carol gains v Bitcoin.

The Lightning payment begins by having Carol generate the preimage x, and gives H(x) to Alice. Next, the payment enters its version of the setup phase, which we refer to as extending a payment. As the payment is extended, the channels along the route set up their timelocked safety nets in the forward (Alice-to-Carol) direction using H(x).

Note that the timelocks are strictly decreasing with every hop that moves us closer to Carol. This forces the next hop to reveal the preimage using the same interlocking that gave us atomicity in the on-chain swap protocol.

With the safety nets in place, we can then settle payment, equivalent to the claim phase from before. To do so, Carol sends x backwards along the route to Alice. If Alice receives an x that matches H(x) from Bob, then she knows the payment was successful, because the only way he could have gotten x is by having extended funds to Carol.

Lightning Swaps

Now that we’ve reviewed the similarities between on-chain swaps and Lightning payments, let’s close the loop on how Lightning can be used to enable off-chain, cross-chain swaps.

With the Lightning payment described above, Alice never receives any money. This poses a problem, as a swap necessarily implies that each of them will end up sending one type and receiving the opposite. We skirt this by having Alice construct a circular route, such that she is both the source and destination of the route. This allows her to be a sender and receiver in the same atomic transfer.

In order for Alice to send Bitcoin and receive Litecoin, she must have a channel open on each chain. The simplest way to achieve this is shown above, with Alice and Bob having a channel open with each other on both chains. That being said, Alice and Bob do not have to be adjacent, so long as a circular route exists back to Alice, and they are straddling both chains.

When executing the payment, the first half of the route carries Bitcoin from Alice to Bob, while on the return, Bob sends Litecoin back to Alice. The ratio between the amount of Bitcoin Bob receives to the amount of Litecoin he sends reflects the exchange rate of the swap. Due to the atomic nature of Lightning payments, the whole swap either succeeds or fails in tandem.

The Experiment

Here is a screenshot of the first Lightning atomic swap. Each party was started with a fixed exchange rate of 100:1 LTC to BTC. The image below depicts:

1. Alice querying lnd for a swap route to Bob, looking to receive 100 Satoshis in

exchange for Litoshis. 2. Piping the swap route back into lnd’s sendtoroute feature, which is able to execute any well-formed route. 3. The route taken upon success, showing that Alice sent out 10,000 Litoshis in the first hop to Bob, and then received 100 Satoshis from Bob on the second hop. 4. The channel balances reflecting the successful swap!

You can watch a video of our second test here, and the modified version of lnd we used for the test can be found on github.

Conclusion

🚀