In my effort to understand more about the lightning network, I came across a lot of posts that either gave a very shallow overview leaving me asking more questions, or posts that simply skipped over the details and linked to the lightning network white paper.
Whilst this series of posts by Bitcoin Magazine is a great in-depth explanation, having read the white paper myself now, I’m hoping to use this post to explain some of the details of the lightning network in beginner friendly terms. I’ll go into details in levels of progressively more complexity, starting from the everyday person who hasn’t heard much about bitcoin, to the enthusiasts that are curious about some of the finer details.
Introduction
Let’s get some simpler stuff out of the way first before going into details:
What is the lightning network?
The lightning network is a protocol built on top of the bitcoin network which allows Bitcoin transactions to take place without needing to be recorded on the blockchain, i.e. off chain.
Why do we need the lightning network?
Each block on the Bitcoin block chain has a limited capacity for transactions. Also, each new block is added on average every 10 minutes. For small transactions then, like buying a coffee, this leads to two issues:
-
No one wants to wait around for 10 minutes at the register to ensure their transaction is confirmed. In fact, given the common suggestion that you should wait for two additional blocks before assuming your transaction is confirmed, this is more like 30 minutes on average.
-
With a limited capacity for transactions in each block, over a 10 minute period, the block will fill up quite quickly and everyone will compete to get their transaction in the block. To increase the chances of being included in the next block, you need to increase the fee you’re willing to pay. At busy times, this can lead to fees over $10 per transaction. A little rich for just your morning coffee.
The lightning network attempts to solve both of the above by making transactions faster and cheaper.
How the lightning network works: Average Joe Level
Assuming everything in the introduction is clear, let’s proceed to explain how the lightning network works to the Average Joe.
I’ve found that a great analogy for the lightning network are tools which help users record IOU tallies between friends, like Splitwise. When you’re out with a group of friends, you might take turns in splitting bills for food and drinks. Rather than immediately reimbursing your share to the one that paid after every bill, you simply record what you owe them in an app, listing how much the bill was and who was included. At the end of the day, you can see how much you owe each person (or how much they owe you) and can decide to settle this balance at any time.
The lightning network works in a similar way. When you’re only making small transactions between people, rather than recording each one on the blockchain, you simply create (or open) what is known as a channel between these two people and record the tally there. At any point you can settle the balance between any two participants by closing the channel, recording the final balance on the blockchain itself.
Also, the lightning network takes advantage of the various links between people, similar to how Splitwise can resolve balances between a group of friends, e.g. Alice owes Bob $10 and Bob owes Carol $10, therefore Alice can simply pay Carol $10. In the lightning network, if you’re trying to transact with someone that you don’t have a direct channel with yet, you can simply find a path of channels to that person and make the payment through these people instead.
Given this handy analogy though, I feel like it’s crucial that I point out an important difference between Splitwise and the lightning network: Splitwise relies on the trust of a group of friends to act honestly, the lightning network does not require this. By default in Splitwise, everyone has the ability to add bills to be split, which updates balances, without requiring the others to consent. Any updates on the balance within a lightning network channel though, require both participants to agree, it’s an explicit payment made from one to the other. For this reason it is known as trustless (a common term used in the crypto world), i.e. it does not require trust.
How the lightning network works: I know a little about Bitcoin Level
If you have a little understanding of Bitcoin, you probably have a few more questions. Like, how is it that the channel balances are enforceable? Which is really where the brilliance (and intricacies) of the lightning network come out.
A key thing to understand right away is that the lightning network’s enforceability primarily relies on sending back and forth actual bitcoin transactions.
When updating the balance of a channel, you’re essentially just creating new bitcoin transactions which reflect the updated balance.
Before we look at an example, we need to understand two things about bitcoin transactions
- Each transaction can have multiple payers (referred to as the inputs) and multiple payees (referred to as the outputs). e.g. Alice and Bob both pay
0.1 BTCfor the input and in the output Carol receives0.15 BTCand David receives0.05 BTC. Obviously it should balance (well, technically the input simply needs to be equal or larger than the output, any leftover output balance is assumed to be a fee paid to the miner).
- Multi signature (or multisig) Wallets are supported, which require multiple users to sign in order to spend funds (sort of like a joint bank account). Lightning relies on a 2-of-2 multisig wallet, i.e. both users must sign for a transaction from this wallet to be valid.
An example
Ok, now let’s take an example (I’m simplifying details here which will be explained in the next section) - Alice wants to pay Bob 0.01 BTC. They regularly transfer small amounts back and forth, so they agree that creating a lightning channel will be more efficient than always transacting on the blockchain. They open a channel between themselves by creating a new bitcoin transaction, where Alice pays 0.5 BTC and Bob pays 0.5 BTC in the input and the output goes to a 2-of-2 multisig wallet which requires both their signatures to use. This opening transaction is then confirmed on the blockchain. Which means yes, opening a channel is not entirely free, you’ll need to pay a blockchain transaction fee to open a channel.
Great, they now have an open channel and can start experiencing the benefit of lightning! In order for Alice to pay Bob 0.01 BTC, they simply create a new transaction, called a commitment transaction, which reflects the updated balance - the input is the multisig wallet and the output is now 0.49 BTC to Alice and 0.51 BTC to Bob. No need to tell everyone else about it, they can simply rest assured that at any time they could submit this as a valid bitcoin transaction, doing so is known as closing the channel.
While the channel is open though, they can transact back and forth quickly and fee free, each time creating a new commitment transaction which reflects the updated balance each time.
But wait a minute - if all these commitment transactions are valid, what stops someone from submitting an older transaction, where the balance reflected them having more BTC? For now, this is enforced by having revoking penalties - if one party attempts to submit an old commitment transaction, the other party can revoke it and claim the entire balance of the channel for themselves. A pretty hefty penalty for dishonesty. How do they work? I promise I’ll explain this in the next section.
Interconnected
Before we wrap up this section though, I want to come back to taking advantage of the interconnectedness of the lightning network. We saw before that if Alice wants to pay Carol 0.01 BTC, but doesn’t have a channel open with her, she can simply pay her via Bob, who does. You can probably see now that this is done via updating their respective channel balances with new commitment transactions reflecting the payment.
But this might create another question: what if Alice pays Bob 0.01 BTC, but Bob never forwards the payment to Carol? This is enforced using what’s known as Hash Time Locked Contracts (or HTLCs), the details of which I hope to explain in a future post. But to simplify, Alice asks Carol to create a secret S (but not to share it with her). Alice then creates a transaction to Bob which says, if you know S I’ll pay you 0.01 BTC. Bob then creates a transaction to Carol saying, if you know S I’ll pay you 0.01 BTC (Bob does this knowing that once he gets S, he can claim the money from Alice straight away). Carol uses S to accept Bob’s payment and as the blockchain is public, Bob then sees S and claims his payment from Alice. Everyone’s happy!
Andreas Antonopolous has a great technical presentation on the lightning network which is around 45 minutes long, which I highly recommend. In particular, the section on payment channel routing (about 5 mins) is a really good explanation of the above:
How the lightning network works: Crypto Enthusiast Level
For a long time I only had the above understanding and the rest felt a bit hand wavy - it felt like explanations amounted to simply “and crypto magic takes care of the rest!”. I’ll attempt to explain some of those details here.
So, let’s take the above example again, Alice and Bob open a channel, paying 0.5 BTC each to a multisig wallet they both have to sign. Nothing different here, the opening transaction is as described above. The extra details now come when we look at the commitment transactions. It was implied above that at any time the current channel balance is reflected in one valid bitcoin transaction which either side can choose to submit. That is not quite the case. If this was the case, old commitment transactions would still be valid which we don’t want. We need a mechanism so that if old commitment transactions are submitted they can be revoked.
Before we look at that though, we need to understand a few more details about Bitcoin transactions:
-
Bitcoin transactions use a very simple language called Script which allows users to specify more complicated conditions for spending coins, other than just simply using private keys. These conditions can be combined with logical operators like
ANDandOR. -
One of these conditions is a time-based (or block-based) lock, i.e. spending is not possible until 3 days from now, or until 6 blocks from now.
-
Given 2-of-2 multisig wallets require two signatures, it’s possible to have a bitcoin transaction which only one party has signed, giving us a half-signed transaction. These can be held indefinitely, with the other party simply needing to add their signature to make it a fully signed and valid transaction which can then be submitted.
Ok, now one of the most important things to understanding commitment transactions: each party holds a slightly different commitment transaction to the other, i.e. they’re asymmetric. Let’s look at a commitment transaction in detail to see why that’s the case.
The guts of a commitment transaction
Back to the example, Alice and Bob now have their funds locked up in a multisig wallet worth 1 BTC (0.5 BTC each) and now Alice wants to pay Bob 0.01 BTC, i.e. the balance should now be 0.49 BTC to Alice and 0.51 BTC to Bob. Bear with me, we’ll look at the details of commitment transactions first and then discuss why they’re like that afterwards.
Both Alice and Bob create a secret but do not share it with the other, Alice creates SA1 and Bob creates SB11. Alice then creates a transaction, CTxA1, spending from the multisig wallet paying out 0.49 BTC to herself and the remaining 0.51 BTC can be spent under the following somewhat complex conditions:
Alice then signs this transaction and gives it to Bob, leaving it as a half-signed transaction which Bob stores securely. He can sign and submit this transaction at any time on-chain.
Quick aside: Hashing
How does Alice create a transaction which requires Bob’s secret SB1 without knowing it? That comes down to something called hashing. Hashing is essentially a one-way function which is very easy to calculate but almost impossible to reverse. Hence calculating the hash of a secret is very easy, but having the hash of a secret doesn’t give you any information about the secret itself.
Hence, once Bob creates his secret, he can simply send Alice the hash of that secret H(SB1) which can be used to create the commitment transaction. The part of the transaction which states that Bob’s secret is required can then say: present something which hashes to H(SB1).
The other side
Now that Alice has sent her version of the commitment transaction to Bob, Bob creates the opposite but equivalent commitment transaction, CTxB1, to send back to Alice. It is essentially the same as the above transaction, switching Alice with Bob and their respective balances in the channel:
Bob then signs this transaction and hands it to Alice, again leaving it as a half-signed transaction which Alice can submit at any point.
But I have questions!
I should hope so. At the moment the commitment transactions roughly reflect the updated channel balance, but we have a few additions that don’t seem necessary at the moment. What’s with the 1000 block wait and why do we need the separate case of presenting secrets?
This is all relevant for when revocation of old transactions occur, but we won’t fully appreciate that until we see the next commitment transaction. At the moment, the above commitment transactions reflect the current state of the channel, but soon they’ll be made outdated and we don’t want them to be used. Let’s see what happens next.
Preventing old commitments from being used
Continuing with the example, Alice now decides she needs to send Bob another 0.1 BTC, making the new balance 0.39 BTC to Alice and 0.61 BTC to Bob. That’s fine, and to do this at some point they will exchange new commitment transactions almost identical to the ones above, reflecting the updated balance. But how do they ensure the old ones won’t get submitted?
To prevent the old commitment transactions from being used, they exchange their secrets from the first commitment transactions (SA1 and SB1) with each other.
Maybe it’s clear already, but let’s see what happens if someone now decides to submit an old commitment transaction. Because to be clear - that’s still very possible, in no way are the old commitment transactions made invalid, it would simply be a really bad idea to do it.
The revocation hammer of justice
After having exchanged new commitment transactions (CTxA2 and CTxB2) with each other to reflect the new balance, Alice decides she’d like to close the channel. But instead of submitting the latest commitment transaction which Bob gave her, CTxB2 where she only has 0.39 BTC, she thinks to herself that she’d prefer to end up with the 0.49 BTC from the first commitment transaction which Bob signed and gave her, CTxB1. So she signs it and submits it on-chain.
Which is fine, no one besides Bob thinks there’s an issue with this. But unfortunately, Alice has to wait a week before she has access to her share. And that gives Bob plenty of time to see that Alice is trying to cheat him by submitting the old commitment transaction. What does Bob do? Not only does he instantly get access to his own share, he presents the secret Alice gave him (SA1) and claims Alice’s share as well.
But what happens if Bob doesn’t see the old commitment transaction being submitted? In reality Bob is actually using a lightning node; software which is continually watching the bitcoin blockchain, looking out for those old commitment transactions which might be presented and striking with the revocation hammer of justice immediately when they are. Which means, for every channel a lightning node has open, they need to remember all the previous revocation secrets to all the previous commitment transactions. For that reason it makes it a little tricky to have a simple seed phrase, as Bitcoin wallets have, to keep a backup - for the time being you need to copy the data from your node to back it up.
Another question: what happens if Bob’s lightning node is offline for more than a week and doesn’t get a chance to submit the revocation transaction? This is still an issue at the time of writing - if you’re running a lightning node, it’s generally a good idea to not have it off-line for more than a week. However, there is a solution to this too, if you plan on being offline for a long time, you can give your revocation information to a watchtower (not naming it after Thor or Mjölnir feels like a missed opportunity). As the name implies, watchtowers are always online, monitoring the bitcoin blockchain, with revocation information from various sources. If they see any transaction that looks like an old commitment transaction, they can submit the revocation on your behalf.
Smooth sailing
But we haven’t fully discussed closing channels yet. Maybe while reading the above, you thought: “wait, does that mean whenever you close a channel someone needs to wait a week to access their funds?”
Thankfully, most of the time that’s not the case. With the knowledge that either side could simply submit the latest commitment transaction balance anyway, if both nodes are online and well intentioned, they’ll simply both agree to sign a simple transaction which pays the current balance to both parties without any additional requirements. However, in the case where a node is offline and you don’t think they’ll be back for another week or so, you can decide to force close on them, submitting the latest commitment transaction.
Which means, the majority of the commitment transactions that are exchanged for every channel update are never submitted on-chain.
And that feels indicative of a lot of the work in the crypto community - a large amount of the time spent on new protocols is on thinking of ways malicious actors can take advantage of it. These systems need to be trustless otherwise no one would bother putting their money into it. But once these rules are in place, because these rules are in place, the vast majority of the details will seem entirely innocent and boring to the average user. Which is exactly how it should be, you shouldn’t need to understand the intricate details of how a system works in order to be a beneficiary of it. You can go and buy your coffee using a lightning wallet, in seconds, fee free, safely in the knowledge that some fairly clever people spent a lot of time considering game theory and security risks to the point that it might be considered paranoia.
Summary
So, if you’ve read this far you hopefully understand the intricate details of how revocation works on the lightning network. But I have some bad news - even though this is how the lightning network works at the time of writing this post, there’s a good chance something called eltoo will cause a lot of that to become redundant. Without going into too much detail (mostly because I don’t understand it yet), it works by chaining the commitment transactions together and no longer uses revocation penalties. However, it requires a small change to the bitcoin protocol, which probably won’t be implemented until later this year sometime. My understanding is that most lightning developers agree it should be the way forward.
I hope this gives you confidence in using the lightning network and encourages you to become an active user. There’s a few good lists floating around of decent lightning wallet apps for both Android and iOS. I’m personally using Breez which is currently in beta, part of Apple’s TestFlight program. Because the list of merchants accepting lightning payments directly is still somewhat limited, I use Bitrefill to buy gift cards for things like Amazon, UberEats e.t.c. As always, even though I spent plenty of time talking about how secure the system is, all of this is still new and you shouldn’t put any money into it that you can’t afford to lose.
-
The notation I use in this post isn’t standard at all, I came up with my own which is hopefully self explanatory, i.e. SA1 is Alice’s secret for the 1st commitment transaction. ↩