A comprehensive guide to the Lightning Network
This weekend Bitcoin’s layer 2 scaling solution, the Lightning Network, hit a record-high capacity of 5,630 BTC — a 42% increase in the last 12 months. This provides ~$172m worth of bitcoin trading capacity and this article provides a comprehensive exploration into what the Lightning Network is and how it works.
Overview
The Lightning Network is a scaling solution for the Bitcoin blockchain which allows it to move from processing 3–7 transactions per second (TPS) to potentially millions of transactions per second! It also offers a cheaper way to send bitcoin with fees of ~$0.84 vs main chain Bitcoin transactions seeing an average fee of ~$2.43.
The reason that Bitcoin can only process a small number of TPS is because there is one block produced every ~10mins and each block is limited at 1MB in size which equates to roughly 2,700 transactions. You can read more about block production on Bitcoin in my previous piece:
This limited block space is also a contributing factor for the transaction fee which must be paid to entice miners to process your transaction. If there’s lots of transactions waiting to be processed then the average fee will increase and this can be seen with the spike in transaction fees around the time Ordinals (digital artefacts [NFTs]) on Bitcoin started to gain traction. It’s also worth noting that whilst the average Bitcoin transaction fee is still comparably cheaper than most fiat offerings, a fee of >$2 is unattractive for micro payments since you wouldn’t want to pay more for the transaction to be processed than the value of the transaction (although I’m guilty of that from my recent escapade into BRC20 tokens and many a wearable or NFT purchase at a congested time on Ethereum!).
This means that you’re needing to process a transaction quicker than the ~10minute confirmation time, or you want to reduce the transaction fee you’re paying, then you need to look at a different solution than the main Bitcoin chain. This could involve using a blockchain with a faster confirmation time e.g Algorand’s 3.3second block time (down from 3.8seconds since their recent v3.6 protocol upgrade) or it could involve using your bitcoin on the Lightning Network instead since this offers near instant settlement, now almost $200m worth of capacity and ultra low transaction fees.
The Lightning Network is therefore a scaling solution, which is built on top of the main Bitcoin blockchain and so referred to as a layer-2 solution, which offers:
- Almost real time settlement
- Ultra low transaction fees
Conceptually, you can think of it as the London tube — with all the roads above ground representing the Bitcoin network of activity and the tube lines below bringing more capacity (and cheaper than an uber!) for people to travel around the city.
The structure of the Lightning Network
The Lightning Network is simply a collection of bidirectional payment channels which are created using the native smart contract functionality of Bitcoin and which utilise cryptographically secured invoices to create a duo ledger system of off chain payments.
Simple right? 😛
Let’s break this all down using the London tube analogy …
The tube system is a map which has stations that are connected by various lines. Sometimes you can travel from one station directly to the next either one hop away e.g Mansion House to Cannon Street, or using multiple hops e.g Chancery Lane to Bank. However sometimes you need to cross from multiple lines and through multiple stations to get from your start location to your destination e.g Mornington Crescent to Knightsbridge.
In the lightning network, the stations represent Bitcoin nodes and the lines connecting them represent Payment Channels. So if Alice wants to send some bitcoin to Bob then either she spins up a Bitcoin node and connects directly to Bob’s Bitcoin node (two stations connected via a line) or she needs to find a route across different payment channels (jumping across lines and stations) to get to Bob.
To take the tube analogy even further, on the tube each line can carry a different number of passengers depending on how many carriages its train has and what configuration the seats are/how many people can cram in. Likewise in the Lightning Network, the capacity of payment channels is different and so allows a max number of bitcoin to travel down it. The aggregate capacity for all payment channels is what gives the Lightning Network its total capacity and so how many bitcoins can be moved across the system at large. Although as we’ll dissect in the next section, a more accurate picture may be painted by looking at the max channel capacities between highly connected nodes.
Nodes (the stations) and payment channels (the lines) are known to all but you don’t necessarily know what the capacity of each channel is and if it’s active. So you often have to have multiple journeys planned and try them one by one. Like consulting Citimapper for your journey planning on the tube but having a back up in case the Central line is horribly busy and you don’t want to be travelling like a sardine!
For a journey on the tube, you may have to go a different route than first anticipated but you always make it back out of the system — there aren’t Londerners wandering the underground forever stuck in there. Likewise payments on the Lightning Network are described as ‘atomic’ meaning that they either complete or completely fail. So if somewhere along the route it fails then the whole route fails and an alternative route is tried. You don’t have partial Lightning Network payments.
We can now explore the structure of the network and it’s capacity with stats from: https://1ml.com/location
Some items to highlight:
- Nodes with public IP indicates nodes which are revealing metadata about their location. Like on the main Bitcoin network, this is optional and nodes could choose to deliberately obscure or misrepresent his information for privacy reasons. Currently the top 3 locations are; the US with 8.70% of nodes, Germany at 3.17%, and Canada with 2.16%. There are 22 nodes reportedly in China, 23 in Russia, and 3 in Iran.
- The average node capacity represents how much bitcoin the node can process through it. Think of this like a station’s capacity for people to travel through.
- The average channel capacity represents how much bitcoin can travel down the payment channel. Think of this like a line’s capacity to move people between stations.
- The ‘node countdown’ is an arbitrary countdown from 1,000,000 nodes.
Payment Channels
Focussing now on the lines between stations — payment channels — let’s dig into how these work and facilitate bitcoin moving around the Lightning Network.
At a technical level each channel represents a UTXO on the Bitcoin Blockchain and is cooperatively controlled by two peers, who can transact through that channel as frequently as they want. It’s a 2of2 multi sig contract — achieved on Bitcoin via a Hash Time Locked Contract (HTLC).
Now that’s a lot of nerdy language so let’s break it down ….
To open a payment channel Alice and Bob must essentially ‘lock up’ some bitcoin on the main Bitcoin blockchain. They do this by creating a Bitcoin transaction where they each send some bitcoin to an address which is controlled by more than one private key. Think of this like a joint bank account. It’s referred to as a ‘multi signature address’ in crypto terminology.
They set this up in two parts.
First they each create a funding transaction e.g Bob committing 3 BTC and Alice providing 2 BTC. This is not broadcast to the Bitcoin network yet but is essentially creating a ‘joint bank account’/payment channel with 5 BTC in and means that each payment channel is represented by a Bitcoin address.
Each then creates a commitment transaction which is sending this amount back to themselves and the other party signs it. In the case that Alice or Bob stops responding or malicious activity is at play, they can broadcast this to get their original funds back. So this transaction isn’t broadcast yet (or potentially at all) but is there ready to use in case things go wrong.
Alice and Bob then broadcast the initial funding transaction and their payment channel with a 5 BTC capacity is created.
However to make use of this 5 BTC capacity, any transactions between them now happen “off chain” meaning that Alice and Bob record them but don’t publish them to the Bitcoin blockchain since this would incur main chain fees and requite processing in a block every ~10mins. Instead Alice and Bob keep track of who’s sending what to each other and to ensure no one can cheat or go rogue, they update their commitment transactions, but again, they keep them in their back pocket and would only broadcast them to the main chain if something goes wrong, or if they want to finalise the state of who has what or close the payment channel.
For a worked example, where Alice and Bob have created a payment channel of 5 BTC with the amounts contributed as noted above, then there will be a funding transaction from Alice of 2 BTC and from Bob of 3 BTC. In their back pockets there will be the signed commitment transaction of 2 BTC going back to Alice and 3 BTC going back to Bob, just in case something goes wrong.
Alice then sends 0.5 BTC to Bob which would result in a pseudo-balance of
Alice 1.5 BTC and Bob 3.5 BTC
This is off chain, but they both update their commitment transaction and get the other party to sign it in case something goes wrong and they need to finalise the state to this point on the main blockchain.
Some time later Alice uses the Lightning Network to send another 0.5 BTC to Bob.
This results in a pseudo-balance of
Alice 1 BTC and Bob 4 BTC
Again, updates to their commitment channels are made.
Bob then sends Alice 0.7 BTC
This results in a pseudo-balance of
Alice 1.7 BTC and Bob 3.3 BTC
Again, updates to their commitment channels are made and waiting in the wings.
There could be any number of other transactions they send between them, with no other on chain transaction recorded on the Bitcoin blockchain other than the funding transaction. This means that the activity between Alice and Bob is happening in ‘secret’ e.g it’s not visible on the Bitcoin blockchain nor is there a block explorer or way to visualise on the Lightning Network since these are all happening off-chain, and between Alice and Bob only.
This is why I’ve referred to them as ‘pseudo-balances’ since this isn’t on chain information.
Let’s say Alice and Bob have now completed all their Lighting Network activity and so want to close the channel. To do this they jointly create a transaction which reflects the final balance e.g Alice sending 0.3 BTC to Bob and broadcast it to the Bitcoin blockchain. This therefore requires one on chain transaction and associated fees, even if on the Lightning Network there were 2, 20 or 2m transactions between them.
But what if Alice and Bob disagree about the current state, closing the channel, or if one of them publishes a previous commitment transaction where the pseudo-balance is in their favour?
This is where our commitment transactions come into play. For each transaction, Alice and Bob invalidate each other’s previous commitment transaction, ensuring that only the most recent transaction can be used to recover their balance in the event of a non-cooperative channel closure. So in the case of disagreement, Alice or Bob can broadcast their last commitment transaction.
Pathfinding
Just like when you’re trying to get from A to B on the tube map you have to figure out which lines to go down and through which stations, doing a Lightning Payment requires you to find payment channels with sufficient capacity to route your payment down. This might be easy to do — if there’s a payment channel between the sender and receiver, or more complex if not.
In some implementations, nodes may outsource pathfinding to an external party to help find the cheapest route (we’ll talk about fees in a little bit) or to find the more efficient route.
Similarly to using the tube, when you see someone at a station or on the tube, you don’t know their destination, routes in the Lightning Network are onion encrypted, meaning only the sender sees the full route. All nodes along the route will only see what channel a payment is coming from and going to and the recipient does not learn the origin of the payment, only of its final hop.
So how are routes chosen?
The three main factors are: fees, channel capacity and channel liquidity.
Let’s consider a scenario, Carol wants to send Dave 10 BTC using the Lightning Network and their nodes do not have a payment channel.
Therefore Carol needs to find a route across different payment channels which ends up at Dave. However she needs every payment channel the payment is going to travel down to have a capacity of at least 10 BTC and it needs to have at least 10 BTC liquidity in — otherwise she’s going to have to split the payment across multiple routes.
Whichever route she picks (and he’s probably going to have a backup or two as remember that Lightning Network transactions are atomic so if any part of the route fails then the whole transaction will fail, so having a backup helps ensure her transaction is successful) she’s going to incur some costs.
From a fee perspective, every node (station) her payment passes through can charge her a routing fee and so Carol needs to take this into account when pathfinding. Each node can set their fee policy independently, although to ensure your channels are used it makes sense to make this competitive whilst still covering any associated running costs for your node and associated payment channels. There are two types of fees:
- Base fee — a fixed fee for forwarding a payment to the next node (typically 1 satoshi)
- Fee rate — a proportional fee for the total transaction amount being routed through your node. This is supposed to compensate you for the capital you’re committing in your channel and the liquidity you’re providing.
How are these fee payments made to the intermediate nodes in the path?
They’re included in the invoice …
Lightning Invoices
So far we’ve looked at the infrastructure of the Lightning Network and how channels are set up and used to route payments, but how does someone actually create a Lightning Transaction to send funds to someone?
On the main Bitcoin blockchain the recipient will share their Bitcoin address e.g bc1pzysdr7ctw5xn22zdpg5cqxpwu52709hu77dwn2wwp22rj9q2f3hsg9sy4g, usually though showing a QR code which represents it, with the sender. Using a wallet, the sender will then create a transaction to send them X BTC. The magic of the transaction processing and raw data creating happens behind the scenes with the wallet so the experience for the user is
- Scan QR code/enter recipient address
- Enter amount to send
- (potentially) select fee to decide how quick the transaction is to process
- Press send and sit back and wait for the transaction to be processed
For a Lightning Transaction things are similar yet different …
The recipient of the transaction will provide a QR code, generated from using a Lightning Wallet but this does not represent a BItcoin address. Instead it’s a Lightning Network invoice which contains all the information about the transaction, route and fees and is valid for a limited about of time.
You can think of this like the instructions Citimapper gives to you get from A to B.
Let’s dissect an example…
- The ‘ln’ at the beginning signifies it’s a lightning network invoice
- Then there’s prefix for the network type bc for Bitcoin, tb for Testnet Bitcoin, bs for Bitcoin signet and bcrt for Bitcoin regtest
- Next is the amount where 2,000,000 satoshis is represented in the above as 20m
- The next parts of the invoice are not human readable but include the timestamp, tags — including, public key of the payee, expiry time for the transaction, and even an optional space for memo data — and a signature
Decoding the above invoice becomes:
From a fee perspective and as noted in ‘route_hints’ the base and proportional fee is included for each ‘hop’ along the route and Carol must include this within the initial amount she’s sending to ensure every stage in the route can be ‘paid’ for.
Let’s look at how this fee payment works for multiple nodes in the path …
Putting it all together to make a payment
As noted before, payments are atomic so either the funds reach the recipient in totality or the funds stay with the sender and no nodes along the route get paid.
This is achieved through Hash Time-lock Contracts (HTLC), which in short make a payment to the recipient under the condition that the recipient produces some secret information — called a preimage.
I tried to think of a tube related analogy here but it just got complicated — so the best way to think of this is that I have some secret `ABC` and I hash it (encrypt it) to a value `XYZ`. I can then share `XYZ` with people knowing that they can’t backwards compute my original value of `ABC` — N.B hash functions, or successful ones, are one way.
If Alice wants to send Dave a payment of 10BTC and they don’t have a channel between them, then Alice needs to find some payment channels connecting them with a channel capacity and liquidity of at least 10BTC (we’re going to ignore multiple route options for ease of explanation).
In this case she’s found a route to Dave via Bob and Carol. Alice then tells Dave she wants to send him 10BTC and Dave sends her an invoice — as we explored above. A key part of this invoice is that he creates a secret value and shares a hash of it with Alice (an encrypted version of it) e.g he’s got a secret value of `ABC` and shares `XYZ` with Alice.
Alice then promises Bob she will send him any fees for passing on a payment if he can tell her what the secret value is in the next 3 days — remember that she only knows XYZ is the hashed version of it. This ‘promise’ is created as a HTLC where Bob can present the secret value to claim the funds in the first 3 days and thereafter the funds go to Alice only. Neither broadcast this transaction though as it’s part of a chain.
Bob can then do the same with Carol so promises to pay her the required fee is _she_ can produce the secret value in 2 days and Carol does the same to Dave if he can produce the secret value in 1 day. Of course Dave knows the secret value — since it’s his secret value so there’s now a chain of promises from Alice to Dave and he can consider the payment complete. He then tells Carol the secret value, who tells Bob, who tells Alice and everyone gets paid their fee.
Conclusion
Like the London underground, the Lightning Network provides additional capacity to the Bitcoin blockchain. It does so by allowing nodes to ‘lock up’ some bitcoin on the main chain and then using this bitcoin as capacity for off-chain transactions. Each node can be connected to any number of other nodes via payment channels, and each of these payment channels has a max capacity and liquidity. When someone wants to create a transaction through the Lightning Network they must find a path (and ideally a back up or two) which has the required capacity and liquidity for their payment amount. They will need to pay fees to each node the transaction is routed through but due to the onion routing mechanism no intermediate nodes know the initial starting point or the destination of the transaction — only the previous and next ‘hop’ along the route.
All these off chain payments are secured by the existence of commitment transactions which any node can broadcast to the main chain and which would finalise the state of the relevant payment channel/s.
This allows nodes and transactors the confidence to have transactions processed off chain, which results in near instant settlement and ultra low fees, rather than requiring every transaction to be processed by the Bitcoin blockchain.
As with the underlying Bitcoin blockchain, the Lightning Network is an evolving protocol and is under active development so for the latest exciting changes and functionality, check out https://twitter.com/lightning .
