Why go around when you can go through?
You’ve probably heard of the Suez Canal (I think it was in the news recently). Before the 120-mile artificial waterway’s creation, European ships bringing textiles and spices from India had to navigate the infamous Cape Route - a 40-something day trip covering some 10,000-plus nautical miles. Then, in November 1869, came the Suez Canal. Now, for a fee, ships could zip directly through the Suez down into the Red Sea. It was a shortcut that trimmed more than 5000 miles and 10-12 days off the journey and it ushered in a new era of maritime shipping. Less time at sea, less deaths from scurvy, less pirates, less malnutrition, less hull-mangling storms. Progress.
And so here we find ourselves in the year of our lord 2021. Global crypto market capitalization is approaching $2 trillion. PayPal is launching a crypto checkout service. Lindsay Lohan is shilling Tron. The Dogecoin Super Bowl commercial didn’t happen, but Elon’s taking it “literally” to the moon instead. Our ascendancy is complete. Crypto is mainstream. But, even today, getting your hands on certain crypto assets can be a bit of an epic journey.
Well, first you’ll need to sign up to one of the centralized exchanges. Then you’ll probably have to go through a time-consuming KYC process. Not only is it a pretty lengthy process, it’s one that involves an uncomfortable amount of trust. Aside from having to share identity documents and other sensitive information with a (potentially anonymous) third-party, you’re also temporarily giving them full custody of your coins or tokens. And just as the precious cargo of those ships navigating the Cape Route made them irresistible targets for marauding pirates, so too do the large concentrations of crypto assets on exchanges make them attractive targets for hackers and social engineers.
So, using a centralized exchange can be slow, it can be costly and it requires entrusting a third party with your money and ID documents. It works, but it’s not ideal. And at the dawn of this new decentralized age with its promise of individual financial sovereignty, it’s starting to look like a pretty antiquated way of doing things.
The idea of Atomic Swaps
We will define atomic swaps as an operation in which two cryptocurrencies, each with its own native blockchain, have the technical ability to create secure exchange operations between network users, while not using trusted third parties and not having to trust one another. For example, Zano and Bitcoin have atomic swaps support, so users can safely exchange Zano for BTC without middlemen, inconvenience and third party risk. The operation is called “atomic”, because it can’t stop half-way through the process. It either happens completely, with both parties receiving the agreed upon number of coins, or it does not happen at all.
HTLC
The atomic swap mechanism is based on the so-called HTLC (Hash-Time Locked Contract). This contract can be roughly translated into human language as follows:
If time passed is less than T, then transfer N coins to address A, if a secret with the hash H is provided.
If time passed is more than T, and during this time the secret was not provided, then transfer the money back to address B (refund).
In other words, the output of the transaction, which is sent as an HTLC, can be spent by the recipient only if the sender reveals the secret to them, and only during a certain time specified in the HTLC (for example, 24 hours). If this does not happen within the specified time period, then the money will be withdrawn to the sender's return address.
Cross-chain Atomic Swaps
Let's describe the process of a cross-chain atomic swap between two parties in detail. Alice has ZANO, and Bob has BTC. Alice and Bob have agreed that they want to exchange a particular amount of BTC to a particular amount of ZANO. Both parties have wallets in both the Bitcoin network and the Zano network.
So, it all starts with Alice generating a random secret. This secret will be the cornerstone of the whole process, so it is important to understand that only Alice knows it. She does not share the secret with anyone, but instead calculates a hash of it, which is used to lock an HTLC transaction to Bob in the Zano network. Bob will not be able to use the output of this HTLC transaction until he learns Alice's secret.
Once Bob has made sure that Alice has created an HTLC in the Zano network - with the agreed upon number of coins and lock-time - he creates an HTLC transaction in the Bitcoin network. Bob's transaction is addressed to Alice, and contains the agreed number of BTC, and (this is important) it is locked with exactly the same hash that Bob found in the HTLC created by Alice, i.e. the hash of Alice's secret.
Alice makes sure that the number of coins in Bob's HTLC transaction to her address in the Bitcoin network corresponds to the amount agreed, and executes the transaction. This decision is essentially the “atomic” moment of the whole process: before it, the deal can be canceled with everyone keeping their coins (having received a refund after a certain amount of time specified in the HTLC), but after it the deal will be “irreversible” in the technical sense.
Unlike Bob, Alice knows the secret that was used to lock the HTLC output of the transaction in the Bitcoin network, so she can create a redeem transaction and withdraw money to her wallet, which she does.
But as soon as Alice creates this transaction and broadcasts it over the Bitcoin network, she reveals her secret (since this secret is explicitly included in the input of the redeem transaction, in order to prove that she knows it). As we know, the same secret is also the locker of the transaction addressed to Bob in the Zano network, so the moment Bob notices this transaction, he extracts the secret from Alice's redeem transaction in the Bitcoin network and uses it to create a redeem transaction in the Zano network:
At the end of the final stage, Alice and Bob are left with the agreed upon amounts of BTC and ZANO respectively. At no point in the process is it possible for one party to go through with their side of the contract while the other does not. The “Atomic” nature of the swap precludes such risks. If either of the parties changes their minds before Alice broadcasts the redeem transaction and reveals her secret, then they can simply wait until the contract expires. It is important to keep in mind that the timelock of the side that creates the response HTLC, the side that does not know the secret, must be chosen in such a way that it is guaranteed to end before the timelock of the side that initiated the operation with the first HTLC. If this is not assured, then the second party (in our case, Bob) may not have time to create his redeem transaction, and might be left without coins.
Connecting different codebase
In example described above, Zano and Bitcoin have a completely different code base, and even different elliptical curves, but fortunately HTLCs allow us to organize atomic swaps even between “genetically” different projects. The only thing that they need to have in common is the hash function used in the HTLC. In the vast majority of cases, the hash is a classic SHA-256, so we implemented HTLC based on SHA-256 in Zano.
Privacy considerations
In the case of Bitcoin, one can hardly talk about privacy, but it is necessary to clarify the specific of work with the privacy blockchain, in which transactions are private by default. HTLC transactions cannot have mixins(anonymity set). Or, more precisely, it would be pointless to include mixins in a redeem transaction, since an HTLC output and a redeem transaction can easily be connected by the hash of the secret (which they both contain). In addition, it is easy to match a pair of HTLC-Redeem transactions in the Bitcoin network associated with a particular atomic swap operation in the Zano network, since the HTLC hash will obviously be the same on both networks.
Practical example
In order to better illustrate how atomics work between two very different projects, we have implemented a small example on nodejs. As a basis for our demo we used this article and this repository, which perfectly illustrate an example of atomic swaps between Bitcoin and BitcoinCash with full clarifications and great guidance. We have simplified the code significantly in order to illustrate the basic principles, however, you wish to deep dive and learn how opcodes form HTLC in Bitcoin we recommend you read the article. Also, keep in mind that this code is provided as a simplified example and is not intended to be used in production “as is”.
P2SH
In the example mentioned above, it is important to understand the P2SH (Pay-To-Script-Hash) concept that is used in Bitcoin for creating HTLC transactions. Bitcoin uses a “script”, a special stack-based programming language. To be more specific, the script that is defined for a specific output will actually be the end of the script, and the beginning of this script will have to be provided by the party which spends this output (for more details, see the article https://bcoin.io/guides/swaps.html).
However, in addition to explicitly including the "half" of the script in the output, there is also a way to send the output script’s hash (P2SH), which means that the content of the output script itself is not disclosed until the moment the output is actually spent. This way, the transaction only contains an indication that both halves of the script must be provided when spending this output - the half from which the hash in the P2SH output was derived, and the half which unlocks the script.
In the example given, this type of output is used to create an HTLC for Bitcoin transactions. Since both parties have agreed on the terms of the deal, and they know their public keys and each other’s public keys (namely public keys and not addresses, because, unlike Zano, in Bitcoin an address is a hash of a public key), then both sides will be able to generate the same HTLC output script, and as a result, both will get the same “script hash address” (P2SH). For one side it will be a “script hash address” (P2SH) to which it will send BTC, and for the other side it will be a “script hash address” (P2SH) that it will monitor (as a watch-only wallet), in order to detect that the HTLC for them is created and confirmed by the network.
Conclusion
Although we’ve used Bitcoin in the above examples, Atomic Swaps can be done between Zano and any other coin that uses the SHA-256 hashing algorithm and supports Hash Time Lock Contracts (HTLC). They provide a more secure and direct route between the ecosystems of Zano, Bitcoin, Bitcoin Cash, Decred, Litecoin, Qtum and others. And the list of compatible assets will only grow.
At the moment these are low-level tools, but they lay the foundations for far greater future interoperability. We’re already seeing platforms being built around Atomic Swap functionality (like AtomicDex) that provide a more accessible and user-friendly experience. Soon these will provide true decentralized alternatives to increasingly regulation-bound centralized exchanges and their limited trading pairs. As the tools are further refined, we can envision a future in which you are free to make fast, low-fee, frictionless and trustless trades between a constellation of hyperconnected crypto assets, each with its own specialized strengths and use cases. And for those who want to transact privately, there will be Zano.
Atomic Swaps means easier access. Easier access means greater liquidity, and liquidity, like fungibility, is something that every good currency should have.
Atomic Swaps. Liquidity. Progress.
PS: This article co-authored with our community member OrsonJ and his help appreciated a lot!
