Submarine Swaps and the era of Trustware.
Since the beginning of this decade when Bitcoin was conceived to be the first viable deployment of a decentralized monetary network, a world of mathematical cryptographic magic has opened up in front of us. This world of magic comprises of obscured number theory tricks and theorems which are slowly but steadily, becoming the foundation of a new age “trustless” world financial system. A system that is independent of winds of geopolitics and human interventionism, and performs like harmonious clockwork. It has been ticking for the last 11 years. Those who have already got the smell of it and sniffed their way into this post in a quest to understand more, you are in for a juicy ride. So buckle up, in this post we are going to explore some very powerful yet simple concepts of distributed trustless financing, and hopefully by the end we understand what the heck is a Submarine Swap.
Atomicity, the unit of trustless contracts.
The biggest magic of Bitcoin is an apolitical global fixed supply monetary system. The next biggest thing it did was to open the doors of trustless contract creation. Often termed as Smart Contracts. Using cryptographic protocols and looking at the Bitcoin blockchain as a source of truth database system, all sorts of financial contracting can be devised and deployed. The magical promise of these new types of contracts is, they are indisputable. Unlike traditional contracts, where disputes are resolved in courtrooms, in the world of smart contracts disputes are impossible.
One giant concept of smart contract design is atomicity, or atomic execution of contracts. Simply it means, if we have two events A and B, atomicity is the mathematical guarantee that either they both happen, or neither of them happens.
These types of conditional occurrence of two events can always be orchestrated using cryptographic protocols (the art of secret sharing), and then they can be used to create cool real-life financial contracts like, “If Bob pays Caroll 5 bucks, Alice will pay 5 bucks to Bob”. And the clause of such a contract might read “Bob can extract 5 Bucks from Alice if and only if he pays Caroll 5 bucks”. Because of the nature of cryptography, there is no room for cheating by anyone. The execution of such contracts will happen in the bitcoin blockchain and neither of Alice, Bob or Caroll would require to trust, or even know each other to perform such a voluntary contract.
Using such atomicity as a pillar of construction, Lightning Network was created to scale Bitcoin transactions per second to VISA level (and possibly higher). Lightning Network is nothing but a chain of such atomic contracts. For example, to make a payment between Alice and Elizabeth the contract flow occurs as: “Alice pays to Bob pays to Caroll pays to Dave pays To Elizabeth” and so on. the promises of such a contract is either the entire payment chain happens, or none of them happen. Because of this guarantee of atomicity, the Lightning Network can route payments globally, without participants knowing or trusting each other.
The building block of such contracts is called HTLCs, on which we focus our attention next.
HTLC Contract Deep Dive.
HTLC or Hash Time Lock Contracts are a specific example of atomic contracting on Bitcoin and is the entire design basis of The Lightning Network. Thus understanding HTLC will not only help us understand LN later, but will directly lead us to understand Submarine Swaps, as they are nothing but simple onchain HTLC contracts.
As the name HTLC suggests, the contract is locked by a hash of a secret value and a lock-time, i.e, it the contract can be satisfied (the coins can be spent) either by providing a secret value (also known as preimage) of the hash, or by elapsing of a certain amount of time.
So a successful HTLC spend is when either the receiver opens the lock providing his signature and the right secret value, or expiry of the lock-time, after which the sender can claim the coins with his/her signature.
Let’s look at a typical HTLC contract.
OP_IF
OP_HASH160 <hash of the secret> OP_EQUALVERIFY OP_DUP OP_HASH160 <reciever pubkey hash>
OP_ELSE
<expiration time> CHECKLOCKTIME OP_DROP OP_DUP OP_HASH160 <sender pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIGThis will be the locking contract (aka ScriptPubkey). And there are two ways of unlocking it. Either by satisfying the IF branch, or by satisfying the ELSE branch.
The IF branch corresponds to the path where the receiver provides the right secret and his own signature, while the ELSE branch corresponds to time lock expiration and spending by the sender’s signature. Alternatively, you can think of the IF branch as the payment path, and ELSE branch as the refund path. Either of them will be triggered depending on the input of this smart contract program (aka ScriptSig).
and ultimately the whole locking script spits out the following contractual clause:
You can extract the money any moment before the time out if know the correct secret, or else I get it back after time out.
And that’s about it. The rest of the magic is just about this secret. This secret can be rewarded to the receiver for the satisfaction of any kind of agreement. Such as paying some third party, solving a math problem, doing your laundry… theoretically anything, as long as completion of the contractual task can be verified and the secret can be communicated to the receiver. And using the properties of atomicity, bitcoin blockchain and clever scripts, any of such agreements can be contractualized in an indisputable way, without any legal cost whatsoever. This is gonna be a big deal.
Finally, Submarine Swaps
Once you understand the spending condition of HTLCs, the rest is really simple. Submarine swaps are just regular HTLCs, but designed for the satisfaction of a specific and simple task: Pay an LN invoice.
And that’s interesting because the payee will pay the receiver via good old onchain BTC. As a result the whole construction is a way of paying someone LN coins, by spending only onchain BTC.
Suppose Alice wants to pay Caroll a LN payment. But Alice doesn’t have a lightning wallet and open channels. The only way available for Alice to perform that transaction now is to get an LN wallet, transfer BTC to it, open channel with few peers and try to route the payment, Which is a time consuming as well as costly affair. The whole workflow is simplified if Alice can perform a submarine swap with third-party Bob, who has LN channels and can then route LN payment to Caroll. Alice locks the required funds in an HTLC with a secret that can only be revealed to Bob if he pays the LN invoice generated by Caroll.
Thus Submarine Swap is a trustless contract to swap between onchain and offchain coins. This can be used very effectively to provide liquidity in the early days of the lightning network, there are already few services live who can perform a submarine swap for you. As you have already guessed, the reverse is also possible, i.e, pay a third-party in LN if they make an onchain transaction for you, with a little bit of extra nuances, and is called Reverse Submarine Swap.
Submarine Swap was first conceptualized by Alex Bosworth and Olaoluwa Osuntokun of Lightning Labs. The name originated from the fact that it’s an atomic swap between onchain(underwater/base layer) and offchain (above water/higher layer) coins.
Now that we understand the basic premises of Submarine Swap, in order to perform one we need Swap Services.
Swap Service
To perform a Submarine Swap, someone needs to make the LN payment for you (the third-party). That’s where a Swap Service comes in. A Swap Service is a server that can perform Submarine Swaps for users. It can be an organization providing the service for a fee or it can be your Swap Server which performs swaps for you and your friends. An open-source implementation of Submarine Swap for a self-hosted swap server can be found here.
As we have already laid out the concept of swapping. Let’s look at a typical workflow of the Submarine swap.
- The user presents to the Swap Service a Lightning Network payment invoice (of the amount of the swap), that in the case of being paid will reveal a secret.
- The user and the Swap Service work together to construct an HTLC that creates a conditional on-chain payment to the Swap Service. The condition is that if the Swap Service can provide a secret within a certain lock-time, it can claim the onchain funds, otherwise after time out, the user can claim back the fund for him/herself.
- The user presents the lightning invoice to the Swap Service. The Swap Service can only know the secret by paying that invoice.
- So the Swap Service pays the invoice and forces the secret to be revealed.
- Using that secret Swap Service can now unlock the onchain HTLC, and claim the funds.
If the server does not pay the Lightning invoice before it expires, it is not able to redeem the conditional payment from the user, so the user waits for the HTLC to reach the time condition and redeem the conditional payment’s funds back.
The Reverse Submarine Swap is also possible where the user pays an LN invoice and the Server Performs an onchain transaction. The workflow is almost similar except for the user and the server switches roles.
A live Submarine Swap Service is can be found here for both mainnet real-life usage (#reckless) and testnet demonstrations.
Application — Liquidity
The most prominent use case of submarine swaps is liquidity management in the LN channel. Most importantly inbound liquidity for merchants. As merchants receive a lot of LN payments, over time their inbound liquidity (funds on the away side of the channel) depletes to such an extent that they cant receive payments anymore via some channels. Currently the only way to solve it is to close the unbalanced channel and open a new one.
A Reverse Submarine Swap (LN to BTC) elegantly solves this problem without ever needing to close a channel. The merchants can simply pay an LN payment to a Swap Service in exchange of for onchain bitcoins. By directing the payment through a specific channel a merchant can rebalance them (i.e. increase funds on the away side) simply by converting his LN revenue into onchain cold storage coins. All of that by just one single onchain transaction.
A vanilla Submarine Swap (BTC to LN) can be used to quickly convert some onchain funds into offchain liquidity.
These two types of swap services are provided by Lightning Loop and are called Loop Out (LN to BTC) and Loop In (BTC to LN) respectively. The Loop client is opensource but the service is maintained by Lightning Labs.
Similar onchain to offchain trustless exchange is also provided -
and by Boltz.
Application — Interoperability
Apart from liquidity management, the next immediate use case is interoperability between onchain and offchain funds. Currently there is no direct way to use these two types of funds interchangeably. This creates a problem of fungibility, as offchain coins are treated differently than onchain coins. Submarine Swap fixes this problem by providing a direct bridge between offchain and onchain liquidity. As a result users can interoperably pay between onchain and offchain payments using swap services. As Lightning Networks grows bigger into the near future such interoperability hugely impacts the health of the system.
Breeze wallet has recently implemented Reverse Submarine Swap where users can use their LN balance to pay to a BTC address.
The Trustless Future
As we have seen, the basis of almost every cryptographic magic on Bitcoin stems from the idea of atomicity. That is mathematically tying two/multiple events such that either they all happen, or neither of them happens. As it turns out such weird and cryptic construction can be the engineering bedrock of our next generation opensource, trustless financial system that is slowly being carved into existence by entire humanity together. As we are seeing a glimpse of the end dates of legacy financial systems, a better way of doing money and finance is not only desirable, but a requirement.
Thanks to Bitcoin this science fiction story came out of the pages of novels directly into the hands of billions of script kiddies and professional engineers, building the next generation of trustless financial software, a.k.a Trustwares.
As we move into this new decade exciting possibilities in the magical world of Bitcoin and Lightning awaits us.
