Interaction Between Protocols
Imagine a scenario where Alice wants to buy a book from Bob’s e-commerce, but Alice only has on-chain funds and Bob only accepts payments through the Lightning Network. How can Alice pay Bob?
If she’s not in a hurry, she could spin up a Lightning node using Voltage’s Nodes and open a payment channel with Bob to make the payment. But even though spinning up a Voltage node is faster than setting up her own hardware, Alice might not want to deal with all the overhead of setting up a Lightning node and opening a payment channel only to pay Bob.
What if Alice talked with her friend, Chan, who has a Lightning node and can pay Bob? She could ask Chan if he could pay the invoice for her, and in turn, she would pay him with on-chain Bitcoin. This can work, but Alice has to trust Chan to make the payment. If she didn’t have any trustworthy friends that run a Lightning node, she would be back to square one.
Wouldn’t it be nice if Alice could make this payment without having to trust the intermediary running the Lightning node? After all, that’s one of the goals of Bitcoin: trustless payments. Well, she can, by using a Submarine Swap: a smart contract that ensures that this payment either succeeds or fails, allowing Alice to get her money back.
A submarine swap is a type of atomic swap. Computer scientists use the term “atomic” to describe a change in state that either succeeds or fails. If the atomic operation fails, then the effect must be exactly the same as if the operation had never been started. Therefore, an Atomic Swap is a transfer of funds that either succeeds or it fails, and no one loses money. At no point, is either side able to walk away with the other party’s funds.
This is the foundation that enables Alice to pay Bob without having to trust Chan or any other intermediary. Interestingly enough, the concept of an atomic swap surged before there was a Lightning Network. That’s because they were initially designed with the goal of exchanging funds across different blockchains, and there are plenty of services in the wild cryptocurrency ecosystem that does that.
Now that we know what atomic swaps are all about, let’s dive deep (pun intended) with the Submarine Swap. We’ll be going through an example where Alice wants to pay Bob’s Lightning node with her on-chain funds.
The HTLC Contract
A submarine swap is, in essence, a smart contract very similar to the HTLC contract that lightning nodes use to send, route, and receive payment through the lighting network. If you need a refresher on the details of how HTLCs work in the Lightning Network, you can read this blog post.
There are two possible paths this payment can go through: a happy path, where everything works out great and Bob gets Alice’s money, and an unhappy path, where something goes wrong along the way and Bob doesn’t receive Alice’s money. The HTLC contract needs to cover these two paths in order to ensure atomic operation.
The Happy Path
Remember: Alice is using an intermediary, Chan, that has a Lightning node and can pay Bob. She’ll pay Chan with on-chain funds and Chan, in turn, will pay Bob. We need to make sure that Chan can only redeem the money Alice sent him if he has paid Bob.
The submarine swap starts with Bob generating a secret value that only he knows, the payment pre-image, and creating a hash from that secret, the payment hash. This payment hash is then sent to Alice, and Bob will only reveal the secret if he receives his money from Chan.
Alice can use the payment hash to create a condition in the smart contract that enables Chan to redeem his payment only if he can provide the secret that hashes to the payment hash provided by Bob. Since Bob will only reveal the secret when he receives the payment, Chan can redeem his payment only if he actually pays Bob. But if the contract allowed anyone with the secret to redeem the money, Chan could be robbed by anyone who knows the secret, therefore the contract also ensures that Chan provides the secret and a valid signature for his node.
The Unhappy Path
But what if the payment fails? There are lots of things that could go wrong: Chan’s node could go offline because of a power outage, or he could refuse to send a payment to Bob because Bob is inscribing NFTs in Bitcoin’s blockchain, and Chan doesn’t like that. Alice needs to be able to recover her money, therefore the Submarine Swap contract needs another clause that enables Alice to recover her money if something goes wrong with the payment.
This can be done with a “timeout” that once expired allowed Alice to recover her funds if Chan doesn’t use the secret to redeem the money locked up by the contract.
The HTLC Contract, Again
This is how the contract is written in Bitcoin Script, as described in the LND documentation:
OP_SIZE 32 OP_EQUAL OP_IF OP_HASH160 <ripemd160(swapHash)> OP_EQUALVERIFY <receiverHtlcKey> OP_ELSE OP_DROP <cltv timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP <senderHtlcKey> OP_ENDIF OP_CHECKSIG
If you’re not familiar with Bitcoin Script on programming in general this piece of code might seem confusing, but don’t worry! This is in essence a contract written in a programming language. In plain English this contract looks like the following:
“Alice will pay Chan if he can provide the following:
- A Secret that hashes to the value provided by Bob.
- A valid signature to ensure his identity.
If a pre-agreed-upon amount of time passes, Alice can reclaim her funds by providing a signature to ensure her identity”.
Executing a Submarine Swap
Let’s execute the submarine swap and see the HTLC contract in action!
1. Bob generates a secret, hashes it and embeds the result in an invoice to Alice.
2. Alice broadcasts an on-chain transaction that locks 50k sats to a contract with the HTLC clauses.
3. Chan sees the HTLC on-chain and pays Bob through the Lightning Network.
4. Bob receives the payment and reveals the secret to Chan
5. Chan uses the secret and his signature to spend the funds in the on-chain HTLC and move the coins to an address he controls.
With Chan spending the coins in the HTLC by providing the secret, Alice can be sure that Bob got paid. She has successfully paid Bob using a submarine swap! If anything went wrong along the way, Alice could await 100 blocks and get her money back by using the timeout clause of the HTLC.
Note that in this example Chan and Bob share a payment channel, but this is not required. The only requirement is that Chan can send a payment to Bob using the Lightning Network, they don’t have to be channel partners.
Submarine Swaps have plenty of use cases. Remember that although we covered a scenario where the money moved from on-chain to the Lightning Network, it’s also possible to go the other way around: move the money from Lightning to on-chain, using a reverse submarine swap.
Besides paying merchants, Submarine Swaps are also useful for Lightning Network routing nodes. They can use a submarine swap to:
- Move bitcoin earned by routing fees into cold storage;
- Manage the lightning node liquidity by making submarine swaps to itself, either increasing the outbound liquidity of a payment channel using a submarine swap or increasing the inbound liquidity by making a reverse submarine swap;
Create your own node below, or learn more about our Lightning Enterprise solution today.
Also enjoy exploring our LSP Flow or test our time series data tool Surge.