Lightning Development: Submarine Swaps and Multi-Path Payments

Last year we wrote a post explaining what the Lightning Network (LN) is to our users. Since that time, the network has undergone a flurry of development and has maintained about 35,000 unique channels and supports approximately 900 BTC in those channels. At today’s prices this is about ~5.8 million dollars (USD) worth of capacity.

Over the past year, there were two developments that caught our attention: the deployment of submarine swaps and support for multi-path payments. Submarine swaps allow users to move Bitcoin in and out of Lightning without opening or closing new channels and multi-path payments aid in the routing of large payments via the Lightning network. 

Submarine Swaps

Before the introduction of Submarine Swaps, on-chain Bitcoin addresses and off-chain Lightning addresses did not have a direct connection. This made it difficult to manage channels and move back and forth between the Bitcoin blockchain and the off-chain Lightning Network. 

Setting up an LN channel requires the creation of an on-chain multi-signature transaction with a commitment of BTC. Unfortunately, there was no way to refill that channel once depleted. Once the commitment of BTC in the channel empties, another channel needs to be opened. Opening channels costs the user on-chain transaction fees, and it’s definitely inconvenient and inefficient to repeatedly open multiple channels.

Submarine swaps solve these issues by enabling Lightning channels to be refilled via an on-chain transfer from the underlying Bitcoin blockchain to the off-chain LN channel. 

Technical Steps of a Submarine Swap:

1. Bob produces or retrieves a Lightning Network payment invoice.
2. Bob presents the invoice to Carol.
3. Carol quotes what she must be paid on-chain in order to pay the off-chain invoice 
4. If Bob accepts, Carol and Bob work together and construct an HTLC (Hash Time Locked Contract) that creates a conditional on-chain payment to Carol.
5. Bob makes the conditional on-chain payment to Carol.
6. The conditional payment to Carol is hash-locked with the same secret that will be revealed if the Lightning invoice is paid. Carol can only redeem the conditional on-chain payment from Bob by making the Lightning payment.
7. Carol pays the Lightning invoice, forcing the Lightning payment recipient to reveal the secret
8. Carol uses the secret to redeem the conditional on-chain payment from Bob.

If Carol does not pay the Lightning invoice before it expires, Carol will not be able to redeem the conditional payment from Bob. In this case, Bob can wait for the HTLC to expire, then redeem the conditional payment’s funds back to herself.

In summary, Submarine swaps enable users to pay someone on-chain to make an off-chain payment for you.

This means that a user can do a few different things:

1. Make Lightning Network payments without being on the Lightning Network
2. Refill their Lightning Network channels (refill) with a fast and low-cost payment on another chain
3. And perform fast trustless swaps between on-chain and off-chain digital assets

Submarine conditional swaps have been demonstrated on the Bitcoin and Litecoin Lightning Networks, using on-chain payments on Bitcoin, Litecoin, and BCH. However, due to the nature of submarine swaps only needing one side of the transfer to be LN enabled, submarine swaps are capable of facilitating cross-chain transfers with chains that aren’t LN enabled, as long as the opposing side is LN enabled.

Money flowing in the opposite direction, as described above, are known as Reverse Submarine Swaps. These solve the off-chain to on-chain transactions and enable Lightning channels to be reversed. This allows users to make room for inbound liquidity via an off-chain transfer to an on-chain address or make a payment to an on-chain address.

Technical Steps of a Reverse Submarine Swap:

1. Bob generates a secret preimage. Think of the secret as a random number that only Bob knows.
2. Bob sends an off-chain (via Lightning) conditional payment to Carol, a “submarine swap provider”. The condition is that the payment needs the secret as an input to be settled or it will return to the payer (Bob) if a determined amount of time has elapsed. As soon as Carol discovers the secret (when Bob reveals it) she could take that money off-chain, meanwhile it will be on hold. We will call this, the swap payment
3. Bob sends off-chain (via Lightning) another payment, called the prepayment, in this case, this is a normal payment of at most a few thousands satoshis, with no condition as its purpose is to cover Carols on-chain fees that are needed to pay for the constructing of a swap structure. In case the swap fails or its cancelled, Bob won’t get this prepayment back, as the provider has already (if she is fair) spent that in the on-chain fees of the tx described below
4. Carol broadcasts an on-chain hash locked output tx. These outputs can only be spent using the secret preimage, (the one only Bob knows). This is the payment to Bob on-chain and the amount of this transaction is the amount of the intended swap. It also has a time condition in case the swap fails, so as we have described we are in front of a Hash Time Locked Contract (HTLC),
5. Bob publishes the secret by disclosing the secret preimage in the spending transaction, so now anyone can see the secret, especially the swap provider Carol.
6. Carol uses the same secret published by Bob in step 5, to settle the off-chain swap payment and Bob uses the secret to claim the on-chain payment made by Carol

Reverse submarine swaps enable users like Bob to make on-chain BTC payments even if they have all their funds committed to Lightning Network channels and they can rebalance their Lightning Network channels by making room for inbound liquidity. 

Multi-path Payments

In December 2019, C-lighning, an implementation of the Lightning protocol, released support for multi-path payments. A major step towards their eventual use in the network. 

Multi-path payments are LN payments that are split into two or more smaller parts and sent using a different route for each part. Smaller payments are more likely to succeed than one large payment. A sufficiently large payment might not be able to find a suitable route to its destination, resulting in a payment failure. Lightning network payments involve a series of handoffs between nodes, ultimately ending at the requested destination. However, if you send a payment larger than a lot of the balances held by other nodes the likelihood of success is very low. 

To solve this, developers have been working on ways of splitting up the large payment into smaller chunks so other nodes can forward those payments and eventually all of the little payments end at the same destination. Right now there are two ways in which this is done. 

Two multi-path implementations:

1. Atomic Multipath Payments (AMP) allow a spender to send multiple hashes all derived from the same preimage (secret #). This preimage can only be reconstructed if the receiver receives a sufficient number of shares (payments). This only allows the receiver to accept a payment if they receive all of the individual parts. Each share using a different hash adds privacy by preventing the separate payments from being automatically correlated with each other by a third party.
2. Base-AMP allows a spender to send multiple payments that all use the same hash, instead of different hashes, and assumes the receiver will wait until the full amount is received before claiming the payment (releasing the hash preimage and allowing generation of a provable receipt). It’s also possible for third-parties who see multiple payments using the same hash to assume they’re part of the same true payment.

However, the privacy for the original AMP comes with a tradeoff. The spender selects all the preimages, so knowledge of the preimage doesn’t provide cryptographic proof that they actually paid the receiver. Base-AMP, although it’s possible for a third party to know if multiple payments are really a large payment split up into parts, the receiver will have a cryptographically provable receipt that the funds were actually paid. 

Conclusion

Both of these proposals bring more utility to the Lightning network. Submarine swaps improve its connectivity not only to the Bitcoin blockchain but also to other chains. Moving from one asset to another is somewhat easy now on-chain but moving from off-chain to on-chain and vice versa with a wide range of assets increases the mobility of assets in the Lightning network quite substantially. Lightning developers want money to be able to flow in and out of Lightning as well as with-in Lightning with ease. 

Multi-path payments are essential to making larger payments in Lightning more reliable. The C-lightning implementation has made great strides in this arena and we expect the routing issues of larger payments to be relegated to the past in the not too distant future.