As its popularity and use has blossomed, and the underlying blockchain lengthened, scaling bitcoin has become a problem. This is because the original vision for the cryptocurrency was that every full node (computer) on the network would keep a copy of every single transaction ever recorded, all the way back to the very first Genesis block.
An upside of this widespread distribution of the ‘ledger’ has been to ensure that the bitcoin payment network is decentralised. Changes can only be made through consensus, there is no single point of failure, and near perfect immunity from hacking or other malpractice.
The downside is that the network is too slow to handle the kind of throughput needed for a modern global payment system.
A possible solution has emerged called Lightning, a payment protocol that will sit as a ‘second layer’ atop the Bitcoin blockchain and allow transactions to occur ‘off-chain’ (i.e. outside of the main public blockchain). Lightning could also provide other benefits beyond scaling too, of greater speed, cheaper fees and improved privacy.
Here we aim to provide a non-technical explanation of the Lightning Network. Note that, although we relate the Lightning protocol to bitcoin in this instance, it is a solution that could be implemented upon any blockchain.
February 2015 – the date that Lightning was first proposed, in a white paper published by Joseph Poon and Thaddeus Dryja (update published 14 January 2016).
Let us first start with an examination and definition of the basic unit of the Lightning Network, namely the Payment Channel.
Payment Channels Explained
A payment channel is a peer-to-peer and private communication between two users, through which one-off or ongoing transactions can occur off-chain whilst remaining secure and enforceable.
Or rather, think of payment channels as IOUs, that are agreed and can only be redeemed when one party decides to cash-out and claim their funds. The difference from a traditional IOU being that payment is cryptographically enforceable even if one party attempts to renege on the agreement.
As we will see, a payment channel alone, whilst being at the foundational level of the Lightning protocol, is only practical between two users. Where Lightning really succeeds is in chaining these payment channels together. But let us first look at how payment channels themselves function.
How Payment Channels Work
Two users – John and Sue – open a payment channel by both sending an amount of bitcoin (say 4 bitcoin each) to a multi-signature address. Once constructed, this payment channel will require digital ‘signatures’ from both John and Sue before these 8 bitcoin can be spent.
At the same time, a second transaction is created and this reverses the first, sending 4 bitcoin back to both parties. This is known as a ‘commitment transaction’ (see below). Once done, the first transaction is broadcast to the network and the channel between the two parties is left open. The 8 bitcoin are now effectively held in a joint account, controlled by both John and Sue.
Until such time as one of the parties decides to close the channel and reclaim their bitcoin, the channel remains open. John and Sue can now transact between each other multiple times, transferring ownership of bitcoin back and forth, without recording anything to the blockchain (for now). Only two transactions are ever sent to the blockchain, the opening and closing ones, with all the intervening changes occurring off-chain.
Commitment Transactions Explained
Using our example – a pool of 8 bitcoin – let us assume that Sue wants to send 2 bitcoin to John.
To do so, Sue would create a new commitment transaction, an update which overrides the previous transaction (in our example, recording the fact that, of the original 8 bitcoin, 6 now ‘belong’ to John and 2 to her).
Later, John wants to send 5 bitcoin to Sue. He initiates a new commitment transaction to override the last, committing 7 bitcoin to Sue with just 1 bitcoin now ‘owned’ by him.
This change in ownership is all still using the funds from the original ‘joint account’ and is all still happening off-chain, with nothing broadcast to the network. Each new commitment transaction updates the ‘ledger’ between the two parties to amend the distribution of the bitcoin in their channel.
But what about trust? Let us assume that the two parties are strangers to one another and therefore cannot naturally trust each other (indeed they may even know one another and still lack trust). What would stop John from submitting the previous transaction to the blockchain, and claim the 6 bitcoin that that version committed to him? This trust issue is cleverly resolved by the use of a revocation key.
Revocation Keys Explained
With payment channels remaining open, and any changes made remaining off-chain until one or both parties decide to close the channel, there needs to be a way to ensure that the latest commitment transaction will not be overridden by an earlier, outdated version.
The solution is a revocation key, an encrypted key that is passed along with the latest commitment transaction and which can be used to invalidate the preceding transaction record.
Should a bad actor attempt to submit a previous transaction to the blockchain, the wronged party has the time and – through the encryption key – the ability to take all the bitcoin in the channel.
So in our last example, John sent five 5 bitcoin to Sue by raising a new commitment transaction that stated that Sue now had 7 and he had 1. At the same time he would have provided Sue with a revocation key for the previous transaction. As the recipient of the new transaction, Sue can now spend her bitcoin immediately. But John would have his bitcoin time-locked for a fixed period (typically a couple of days).
As the sender of the last commitment transaction, John cannot spend his bitcoin without Sue’s signature. If he tries to submit the previous transaction (the version in which he had 6 bitcoin, not the current 1), Sue would be aware of the fact and could then use the corresponding revocation key to take all the bitcoin in the channel, including any bitcoin belonging to John contained within the joint account.
Thus, bad actors are discouraged from cheating due to the penalty they would incur from attempting to do so.
Closing a Payment Channel
Eventually, when the parties are ready to cash out and receive the bitcoin due to them, the sender of the most recent commitment transaction can request that the recipient sign a transaction that closes the channel. This allows both parties to receive the funds owed to them, without time restrictions.
Otherwise, if the sender wants to close the channel unilaterally they will have to wait for their funds to be made available to them, as explained above, whilst the recipient can claim their own without a wait. However, the former approach is obviously preferred and thus fair play is encouraged.
Once the channel is closed, only the original opening transaction and the closing transaction are submitted to the blockchain. None of the intervening commitment transactions, which all occurred off-chain, need to be included in the record.
Chaining Payment Channels
So far we have described an off-chain method for enabling multiple transactions between two people. But the real power of the Lightning Network is in its ability to chain multiple payment channels together. This allows users to send bitcoin to lots of different people without requiring direct channels with every recipient.
On the Lightning Network a user may have payment channels open with just a couple of other people yet be able to send funds to many more, and all still occurring off-chain. The direct channels they open will simply become the first link in a chain through which they can forward funds to others.
Let us assume that John has a channel open with Sue, among a number of other users. Sue has a channel open with Adrian, among others. Adrian has a channel open with Rachel, among others.
John wants to send bitcoin to Rachel, but there is no direct channel open between them. To get the funds to Rachel, John can send them along the line, without needing to know each person in the chain.
And to incentivise their help, each intervening person in the chain would receive a small fee from the original sum.
Again, though, a potential trust issue arises, and again, the protocol answers this with a cryptographic solution. The solution is known as a Hashed Time Lock Contract (HTLC).
Hashed Time Lock Contracts Explained
In a system of chained transactions, with third parties relaying payments onto the eventual recipient, a trust issue arises. In our earlier example, where payment is made from John to Rachel via Sue then Adrian, what is to stop Adrian from retaining the funds for himself, with or without collusion from Sue?
The answer is a nifty cryptographic mechanism called a Hashed Time Lock Contract (HTLC). With this, the eventual recipient – Rachel – would choose a random value (R) and use a one-way hash function to generate a hash value (H). Rachel sends H back along the chain to John via each participant.
Next, the first two people in the chain, John and Sue, sign a HTLC that requires that Sue provide John with a value that hashes to H in order to get paid (of course, Sue can only do this if she is eventually told R, which must come back from Rachel via Adrian). Sue and Adrian then sign a HTLC also, with the same conditions, and Adrian does the same with Rachel.
The contracts for payment can then be settled in reverse order. Rachel tells Adrian the secret value R and gets paid. Adrian then tells Sue the value R and they settle their contract. Finally, Sue can give value R to John and get paid by him.
In this system, because Rachel will only reveal R when the payment chain is complete, the first person in the chain – John – can feel confident in signing a contract with Sue.
The thing that makes this system workable is the fact that it is enforced by the blockchain. As long as each actor learns R from the next person in the chain, they are guaranteed to get paid. This is because a more sophisticated commitment transaction is employed which, as well is creating the two outputs as per the basic commitment transaction, creates a third output which effectively puts the funds under contract into escrow.
This third output can be redeemed in one of two ways. Either the recipient at any point in a chain can confirm the value R (hashing to H), or the preceding user can cash out after a fixed time period has elapsed.
At each hop along the chain, this fixed time period gets shorter so that, if Sue cannot provide R to John, he can get his funds back after 3 days. If Adrian cannot reveal R to Sue, she can reclaim her funds after 2 days. And if Rachel does not reveal R to Adrian, he gets his funds back after a day.
By reducing the lock-in time as the chain progresses, each person can be confident of reclaiming their funds if any payment fails. If Adrian were to disappear from the network and fail to provide the secret value R to Sue, she could close the payment channel, broadcast their commitment transaction to the blockchain, and reclaim the bitcoin from the multi-sig address.
But John and Sue, transacting earlier in the chain, would have longer to react to Adrian’s disappearance, giving them the option of creating a new commitment transaction and thus keeping their payment channel open.