What is a Submarine Swap?
A few weeks ago I wrote a long read about the Lightning Network, a layer 2 scaling solution for Bitcoin which allows users to make off-chain payments with near-instant settlement and near-zero fees.
You can read the full piece here: https://tara-annison.medium.com/a-comprehensive-guide-to-the-lightning-network-aa2f7f9c6c31
One of the key concepts of the Lightning Network is opening up a channel between two parties to be able to transact off chain. As such Alice and Bob will lock up funds on the main Bitcoin chain and then be able to transact up to these balances between them. Other users can also have their payments routed down Alice and Bob’s channel to get to other destinations.
However, consider the following scenario:
Alice initially locks up 7 BTC on the main chain
Bob initially locks up 5 BTC on the main chain
They, therefore, have a total channel capacity of 7 BTC from Alice to Bob and 5 BTC from Bob to Alice. After some number of offchain transactions between them, Alice now has an effective balance of 0.5 BTC and Bob has an effective balance of 11.5 BTC. However, this leaves Alice short of liquidity through the channel and if she then wants to send another 2 BTC to Bob she doesn’t have sufficient funds.
Alice then has a few options.
She can close the channel out with Bob at the current state and reopen another channel with an additional balance. However, this takes time to close the existing channel (and an on-chain transaction) and open a new channel (another onchain transaction) and carries the associated fees of these onchain transactions.
Or she could perform what’s known as a submarine swap with Bob.
Here she sends him an on-chain transaction of 2 BTC to his Bitcoin address and Bob reflects this by creating a Lightning Transaction back to her for 2 BTC. As such Alice now has an effective Lightning balance of 2 BTC and Bob’s balance is 9.5 BTC.
As with other Lightning transactions, this is an atomic transfer — meaning the full transaction (both Alice’s onchain part and Bob’s offchain part) either fully happen or don’t happen at all.
So how does this work in practice?
Alice creates a secret (known as a pre-image) and encrypts it (known as hashing). She shares this hash with Bob. Bob and Alice then exchange a public identifier for themselves (known as their public key).
Alice then generates a Bitcoin address with the following spending conditions:
1) Before time t, the funds can be spent by knowing the secret and providing a signature from Bob’s public key
2) After time t, the funds can be spent providing only the signature for Alice’s public key
Alice then generates a Lightning Invoice for Bob to send her 2 BTC. She uses the secret from her onchain transaction to construct the lightning transaction and so once she reveals this secret then Bob will pay her.
However, once the secret is revealed, assuming all this happens before time t, then the first spending conditions for the onchain funds can be met since Bob now knows the secret and he can provide a signature from his public key. This means the 2 BTC from Alice are redeemed by Bob.
If Bob had failed to send the Lightning funds then Alice could have waited until after time t and created a signature from her public key to take back her 2 BTC using spending condition 2.
This approach, therefore, allows Alice to increase her Lightning balance without having to close and reopen the channel with Bob, all by sending an onchain transaction to him which is for less than or equal to his Lightning balance with her.
However, since 2017 there’s been Lightning users asking why channel balances can’t be ‘topped up’ as this would provide a more effective and quicker route to re-balancing and having access to liquidity. This is something that can now be achieved with ‘channel splicing’ — the act of adding additional funds to a channel from your onchain address without having to open a new channel. However that’s a topic for another post …
Originally published at https://www.linkedin.com.
