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 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 must trust Chan to pay. She would be back to square one if she didn’t have any trustworthy friends who run a Lightning node.

Wouldn't it be nice for Alice to make this payment without trusting the Lightning node's intermediary? After all, that’s one of the goals of Bitcoin: trustless payments. By using a Submarine Swap, she can, a smart contract that ensures this payment succeeds or fails, allowing Alice to get her money back.

Atomic Swap

A submarine swap is a type of atomic swap. Computer scientists use the term “atomic” to describe a state change that succeeds or fails. If the atomic operation fails, the effect must be the same as if the operation had never been started. Therefore, an Atomic Swap transfers funds that succeed or fail, and no one loses money. Neither side cannot walk away with the other party’s funds.

This foundation enables Alice to pay Bob without trusting 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 to exchange funds across different blockchains, and there are plenty of services in the wild cryptocurrency ecosystem that does that.

Submarine Swap

Now that we know what atomic swaps are all about let’s dive deep (pun intended) with the Submarine Swap. We’ll go 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 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 to ensure atomic operation.

The Happy Path

Remember: Alice uses an intermediary, Chan, with 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 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? Many things could go wrong: Chan’s node could go offline because of a power outage, or he could refuse to pay 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 allows 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 unfamiliar 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.

In this example, Chan and Bob share a payment channel, which 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.

Use Cases

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.

Share this post