Did you know that it is possible to swap your on-chain Bitcoin with someone else’s lightning funds or the other way around without any trust or risk?
How does that work?
Why might you do it?
I’ve been working with lightning for years, let me break it down for you 👇
How does that work?
Why might you do it?
I’ve been working with lightning for years, let me break it down for you 👇
These swaps are called submarine swaps and use similar concepts to those used with regular lightning payments.
If you need a quick refresher on how HTLCs work, what hash locks are, and what time locks are then see my earlier thread here:
If you need a quick refresher on how HTLCs work, what hash locks are, and what time locks are then see my earlier thread here:
https://twitter.com/JohnCantrell97/status/1482746466703716357
With swaps, let's call the person sending on-chain funds and receiving lightning funds the sender and the person receiving the on-chain funds but sending lightning funds the recipient.
So when I use the term sender and receiver I’m referring to movement of the on-chain funds.
So when I use the term sender and receiver I’m referring to movement of the on-chain funds.
Just like with a lightning payment the person who wants to receive funds over lightning (the on-chain sender in our swaps example) creates a random number called the payment secret or preimage and then uses it to calculate the payment hash.
They construct a tx that has two payment paths:
1. Pays to the receiver’s pubkey only if they know the preimage
2. Pays to sender after a delay
The sender can release the payment to the recipient by providing the preimage OR they can wait for the delay to reclaim their funds.
1. Pays to the receiver’s pubkey only if they know the preimage
2. Pays to sender after a delay
The sender can release the payment to the recipient by providing the preimage OR they can wait for the delay to reclaim their funds.
The sender creates a lightning invoice using the same preimage they used to construct the on-chain tx and gives it to the on-chain recipient to pay.
The stage is set.
When the recipient pays the invoice they will receive the preimage and be able to claim the on-chain funds.
The stage is set.
When the recipient pays the invoice they will receive the preimage and be able to claim the on-chain funds.
If the recipient fails to pay the invoice then the original sender can just take their money back after the time delay.
Funds are never at risk because the other party must pay the lightning invoice in order to get the secret to claim the onchain funds:
Funds are never at risk because the other party must pay the lightning invoice in order to get the secret to claim the onchain funds:
The sender only reveals the preimage after they have received the funds over lightning.
The receiver will receive the preimage if they pay the invoice.
The receiver can compare hashes in the invoice and the on-chain tx to be sure the preimage will unlock the on-chain funds.
The receiver will receive the preimage if they pay the invoice.
The receiver can compare hashes in the invoice and the on-chain tx to be sure the preimage will unlock the on-chain funds.
This technique is useful to manage the liquidity of your lightning channels.
It’s a great way to get incoming liquidity and for moving any extra funds you might have in lightning back into an on-chain wallet for secure storage without closing the channel.
It’s a great way to get incoming liquidity and for moving any extra funds you might have in lightning back into an on-chain wallet for secure storage without closing the channel.
I hope this helped you understand how submarine swaps work and why you might want to use them. They are a powerful tool for managing your lightning node.
Be sure to follow if you want to continue learning about Bitcoin and the lightning network.
Be sure to follow if you want to continue learning about Bitcoin and the lightning network.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
