A beginners guide to the Lightning Network
This page aims to help people understand a little more on the mechanics of Lightning and how it interacts with the underlying Bitcoin network. We aim to achieve this by using simple terminology and without getting too deep into the technicals, although there will be some further reading linked for those that want to take things a step further. Thanks to the developers of the various applications that interact with Lightning, many of the concepts outlined here are obfuscated away behind simple user interfaces. However, it always pays to have a good base level of understanding to help a user be more aware of what is happening when they send or recieve a payment via Lightning.
Theory is great but there’s nothing quite like getting your hands dirty! Once you’re set up, feel free to send me an invoice for a few sats to test your setup.
Download Breez, backup your seed phrase and you are ready to receive via Lightning. Your channels are managed for you (for a small fee) and you can even send/receive Bitcoin on chain. The app will deal with this on your behalf using submarine swaps and will send or deposit the equivalent amount of sats via Lightning. Here is what that process looks like.
If you want to do things through your own node, then using an implementation such as myNode or RaspiBlitz makes set up easy. They come pre packaged with node management tools like RTL and Thunderhub and make connecting mobile wallets like Zap or Zeus very simple. Here is a simplified workflow for using these processes…
The Bitcoin ‘base layer’ (the blockchain) cannot facilitate enough transactions to allow billions of people to use it every day. For example, if a couple of million people suddenly wanted to start using the network daily for everyday purchases, the transaction queue and fee rate would quickly spike as people compete to get their transactions processed. To aleviate this and enable the network to scale to cope with the expected exponential increase in transaction numbers, a layered system is being worked on and rolled out, much like the Internet Protocol stack.
Of course these transaction levels could be drastically increased by using a centralised database, similar to the current financial system we have today. But that wouldn’t be very ‘Bitcoin’, would it? Transactions could be censored, privacy would be non-existant and we would be no better off. Enter the original ‘layer 2’ Bitcoin solution, The Lightning Network.
The Lightning Network is scaling solution built on top of the Bitcoin protocol. It facilitates smaller, near instant payments between users at very low cost. It prevents the need for every transaction made to take place on the Bitcoin ‘base layer’ whilst still ensuring that the value being transacted abides by the rules of the Bitcoin network. It is trustless, with no centralised databases and every part of the Lightning Network starts from and finishes up, on the Bitcoin blockchain. Users can exit ‘layer 2’ and return to the base layer at any time they like.
A visualisation of the Lightning Network by Acinq
The Lightning Network consists of thousands of two party payment channels. These payment channels enable those two users to pay one another back and forth as many times as they like, almost instantly and with no blockchain fees.
A channel is opened by one or two users locking up an amount of sats into an on chain ‘funding transaction’ that creates a 2 of 2 multi-signature wallet on the Bitcoin network, with each user receiving one of the keys. The opening channel ‘state’ will reflect the amount a user contributes and each party will sign off to say that they accept this is correct. This ‘sign off’ is actually an unbroadcasted Bitcoin transaction containing the signature of both parties which are passed to one another via the Lightning network. These signed but unbroadcasted transactions allow either party to close the channel at any point and ensures the sats contained within are returned ‘on chain’ to their rightful owner.
Simple illustration of a channel open transaction
Each time a payment is made from person A to person B, sats are pushed from one side of the channel to the other (think beads sliding along an abacus). The two parties then sign a Bitcoin transaction to reflect the updated channel balance of each and pass across to the other participant. This process can be repeated an unlimited amount of times and these signed transactions are only ever broadcast to the Bitcoin network in the event of a channel closure.
Simple illustration of a direct channel payment
You can open a channel with pretty much any network participant you like, however there are a number of things to consider before doing so…
You can compare these stats and many more when choosing a peer at 1ml or use a simplified version here that gives nodes an aggregated score based upon a combination of things like uptime, liquidity and how well connected they are. It then displays the best 5%.
Much like a channel open, a channel closure is an on-chain Bitcoin transaction. Channel closures occur when one or both parties want to settle their balance back to the Bitcoin network. There are three types of channel closures that can occur with Lightning and in all instances the fees are paid by the person that opened the channel.
Where one party initiates a channel closure, communicates this with their channel partner. Both parties agree to close the channel and the most recent state is broadcast to the network and each participant receives their sats back to their on chain wallet. This scenario covers the vast majority of all Lightning channel closures.
Where one party closes the channel without the consent of their counterpart. These types of closures generally occur when one of the channel parties is unreachable. For a force close to take place, one user simply broadcasts the most recent channel state known to them. Once a force close is confirmed onto the blockchain, the user that initiated the force close will have their balance locked for a set amount of time. This enables their counterparty to see the channel close and come back online to confirm the channel state. If this does not happen, the party that closed the channel’s on chain funds will become spendable after the lock time (usually 2016 blocks or two weeks) has ended.
A disputed close arises from a force close being initiated. If the initiating party publishes an old channel state that favours them and pays them more sats back on chain, the party having the channel closed on them can dispute the closure if they disagree with the outcome. To trigger this dispute they simply bring their node back online within the lockout period (typically 2016 blocks or 2 weeks). Alternatively if that isn’t an option because their node is in a different geographical location, they may have chosen to set up a Watchtower service that will monitor their channels and act on their behalf for a small fee.
If the party creating the dispute can successfully publish a more recent channel state than the one broadcast by their channel partner, their node will be able to publish a Justice transaction and claim the entire balance of the channel. The threat of such a scenario is enough to ward off most dishonest Lightning operators for fear of losing all of their funds.
Lightning transactions are settled within a few seconds and cannot be recalled, undone or subsequently altered. The clever thing is, Lightning achieves this without the need to wait for a block confirmation on the blockchain whilst still maintaining Bitcoin’s security principles because any Lightning participant can settle on chain whenever they like.
Being able to do fast and cheap payments to a single user might be beneficial if you are conducting many transactions but don’t forget that each channel has a blockchain footprint of two on chain transactions, so opening a channel to do just a couple of payments is counter productive. Lightning is not always the answer. So what happen’s when a user wants to make a Lightning payment to someone they don’t have a channel open with, surely they don’t need to have to open channels with every person they want to transact with?
Thankfully not, this is where the Lightning Network starts to shine! Provided you have 1 or 2 channels to fairly well connected nodes, you can route transactions to people you aren’t directly connected with, via people you have a direct connection (a channel) with.
Alice routing a payment to Dan, despite not having a direct channel with him.
This type of multi-hop transaction is carried out in a trust free way using a process called onion routing. This method allows for secure transfer of ‘messages’ known as Hashed Time Locked Contracts or HTLC’s. HTLC’s are structured in such a way that each ‘hop’ only sees the information they need to take their fee and continue the payment to the next participant in the route until it reaches the final destination, the recipient.
Here is a simplified run down of what happens for the transaction above to be successful. It sounds complicated, but it all happens under the hood in a matter of seconds.
There are no ‘real world’ identities in Lightning, the names above are purely for illustration purposes. Each participant has a Node Public Key which acts as their ‘Lightning ID’.
Whilst the Lightning Network provides a fantastic scaling solution for Bitcoin, it of course has some limitations. These are outlined breifly below…
Channel management - If a user makes a lot of payments in a single direction, channels can become unbalanced, meaning that all of the funds are stuck on one side of the channel. This then requires the user to take action by balancing their channels. This can be done by circular rebalancing (paying yourself out of one channel and into another) or via a submarine swap service that allows you to drain off or fill up an existing channel for a small fee. Most of the common Lightning node management tools have some form of swap service built in.
Channel Size - If a user opens a channel for 1 million sats and then needs to make a payment of 1.5 millions sats, they cannot do so without the use of Multi Path Payments which allows the use of more than one payment channel controlled by a single user to route a transaction. Fortunately, this is fast becoming standard practice and hugely increases the user experience and improves payment success rates
Route liquidity - If Alice wants to send a large payment to Dan over Lightning, she needs all of the people on her chosen route to have at least that amount of channel balance otherwise the payment will fail. This only really becomes an issue for larger payments.
Hot Wallets - Due to the nature of the Lightning network, a user’s Lightning node needs to be online 24/7 to acknowledge and sign transactions back and forth. This means that it is advisable that users do not lock up large amounts of bitcoin without taking proper security and backup precautions.
Do I need to use Lightning?
There is no right or wrong answer here. At present Bitcoin fees are still fairly cheap which makes on chain transactions acceptable for 95% of users. But for those who regularly transact using smallers amounts, Lightning presents the opportunity to save on fees and also benefit from near instant transaction settlement.
Do I need a node?
Much like Bitcoin, you don’t need a node to interact with Lightning, but running your own is the most private and secure way to do so. If you aren’t trusting your own, you are trusting someone else’s. Fortunately, most of the common Bitcoin nodes come packaged with a Lightning implementation too. Check them out in the Lightning tools section below.
Who maintains the Lightning Network?
The Lightning network is an open protocol that many people work on and contribute towards, all implementations work to the B.O.L.T open standard and the common implementations are completely interoperable. They are…
Is there a ‘Lightning coin’?
No, Lightning transactions essentially transfer ownership of bitcoin from on person to another.
Why do payments fail?
Payment failures occur for many different reasons, however the most common is that the node you are transacting through cannot find a suitable payment route to the destination.
What does balanced channels mean?
Having a balance channel simply means that you have a fairly equal amount of sats on both sides of your channel. Think of it like an abacus where there are an equal amount of beads on each side. This ensures the user is in the best position to send or receive via Lightning, it is also beneficial for those wanting to earn sats by being a routing node, though that concept is for the more advanced user.
Using the example below, the blue balance on the left is the ‘local balance’. This represents the size of the balance on my side of each channel and is how much I can spend within each. The green balance on the right is the ‘remote balance’. This represents the size of the balance on my peer’s side of the channel and is how much I can receive within each.
Channel balance graphs from Thunderhub.
How do I balance my channels?
What happens if my node breaks while I have open channels?
The optimal solution is to revive your node and avoid the need to close your channels in the first place, however this won’t always be possible and this is where backups are crucial. You can import your Lightning Wallet seed and static channel backup file into another Lightning Node which will trigger a closure notification to all peers and return your sats back to your on chain wallet This process is possible through the command line but is the easiest way to do so is through interfaces like RTL or Thunderhub. Another outcome could be that a Lightning peer may notice that you are offline and choose to force close the channel (hopefully in an honest manner), this will return any sats in that channel back to your on chain wallet.
Why do my channel balances change over time?
This is likely because someone has routed a transaction through your node. This has the effect of moving some of the balance from one side of the channel to the other. If you do not want this to happen, you can specify that your channel is private at the time of opening. This effectively shields it from view for the rest of the network.
How do I get my sats off Lightning?
You can close a channel, which will refund your balance back to your on chain wallet. Alternatively, if you have received a lot of Lightning payments and your channel balance is getting full, you can complete a loop out which will drain a percentage of your channel balance back to an on chain wallet, freeing up some channel capacity for you to receive again. The reverse operation (loop in) can be used to ‘top up’ your channel balance if you have made lots of payments and no longer have sufficient outbound liquidity.
CoinOS offers another good solution for swapping between on chain and off chain with ease. Be sure to use the non-custodial option to negate any third party risk.
Can I make my channel larger after I have opened it?
No, channel sizes are fixed at the time of opening. However, you can leverage multiple channels at the same time using Multi Path Payments.
Can I make money on the Lightning Network?
Yes, technically you can earn sats via routing. However, the gains to be had vs the node and channel management required put this practice out of reach for the average Lightning user.
How much does it cost to open or close a channel?
That depends on the current state of the Bitcoin mempool at the time and the fee rate negotiated with your channel partner.
What is Keysend?
Keysend is a development that allows for spontaneous payments to be routed without an invoice.
What are MPP?
Multi Path Payments allows a user to send payments that are larger than the capacity of their single largest channel by utilising the liquidity of more than 1 channel at the same time. This needs to be active at the node level
If after reading this guide you want to try Lightning for yourself but think you’d benefit from a more personalised tuition approach, I offer private support calls.