What is the Lightning Network?

The Lightning Network was a proposal made in early 2015 by developers Joseph Poon and Thaddeus Dryja to increase the scalability of Bitcoin, specifically, and blockchains in general.

Scalability of blockchains is all about the potential transaction throughput of these networks. Blockchain based networks require a large amount of parties to keep track of every transaction ever made on their respective networks. Over time, this will be a considerable amount of information that needs to be maintained by entities of varying technological and economic means. Many use the following analogy to drive home the point: Imagine that every email ever sent had to be stored and tracked by everyone who wants to run an email server. This would be a considerable burden on everyone and every organization that wants to run an email server.

In addition, many blockchains have a somewhat but not entirely arbitrary limit on the size of blocks that can be produced by miners. Consequently, the number of transactions that fit in each block are inherently limited. Some networks have opted to increase the block size to allow more transactions into each block in the blockchain. The debate around block sizes, nodes, and on-chain vs off-chain scaling is at the core of the Bitcoin and Bitcoin Cash schism.

Increasing the blocksize is known as on-chain scaling, meaning the blockchain itself will have increased transaction throughput per block. Off-chain scaling avoids throughput increases on the blockchain itself in favor of moving transaction capabilities to other complimentary networks.

Moving transactions off of the blockchain onto complementary networks removes the necessity to record every transaction ever made and avoids the throughput limit imposed by a blocksize. These off-chain networks reduce the load on nodes that keep a record of the full history of their blockchain and makes the potential transaction throughput close to infinite. The Lightning Network is one such complementary network.

Keep in mind the Lightning Network is not an independent or separate network but rather a dependent network. Meaning it only works with the support of an underlying blockchain for security and its scripting language for its operation. Off-chain solutions like the Lightning Network essentially anchor in to an existing blockchain. A blockchain works with or without the Lightning Network. The inverse is not true.

An analogy helps explain the purpose and thinking behind Lightning as a scaling solution:

One that is often brought up are private contracts and the court system. The overwhelming amount of private contracts are negotiated and executed without  the court system knowing anything about them. If the court system had to mediate every private contract we’d have a very inefficient economy and a bloated judicial system. Instead, parties only go to court when there is a dispute to adjudicate. The private contracts are anchored into an existing court system which is utilized when there are disputes. This is rare, but it happens. The number of contracts and economic transactions that can be made without the court system knowing anything about them is close to infinite. The Lightning Network and other off-chain networks work in a very similar manner.

How Does Lightning Work?

There are two key technologies that make the Lightning Network work: Multi-signature smart contracts and hashed time-lock contracts.

Multi-Sig

Multi-signature smart contracts are the foundation of the Lightning Network. Standard Bitcoin transactions only require one cryptographic signature from one party. Multi-signature transactions, or multi-sig for short, allow for a lot of different transaction types to be programmed and for multiple parties to participate.

For example, two Bitcoin users can set up something called a “payment channel” by creating a 2-of-2 multi-signature transaction on the Bitcoin blockchain with at least one of the parties committing funds to the channel. Both parties are anchored into the Bitcoin blockchain by a multi-signature contract and can now send signed Bitcoin transactions back and forth indefinitely between each other without the need to broadcast all the transactions to the Bitcoin blockchain. Instead, the two channel participants keep track of the channel balance and only broadcast the latest balance of the channel if they wish to close the channel.

Let’s imagine each participant in a payment channel funds the multi-signature contract with 5 bitcoin each for a total channel capacity of 10 bitcoin. They can transact theoretically an infinite amount of times without paying mining fees on the transactions, nor waiting 10 minutes for confirmations on each transaction. The transactions in the channel are cheap, unlimited, and instant. However, each party has to keep track of the proper distribution of bitcoin in the channel, otherwise known as the channel state.

This dynamic is similar to opening a tab at a bar. If a customer plans on ordering multiple drinks and the bartender asks the customer if they want to keep a tab open, the customer will likely say yes for his own convenience’s sake and the bartender will say yes to save time and money. The bartender will take possession of the customer’s credit card and instead of charging it each time the customer orders a new drink the bartender will keep track of the “channel’s state”, or how many and what type of drinks the customer has ordered. Once the customer asks to close the tab, the bartender will charge their card once and will give a receipt to the customer asking him to check its accuracy and sign off on the transaction. Even though multiple credit card transactions could have been made, it was reduced to one transaction. The customer and the bartender have set up a unidirectional payment channel which allows many transactions to take place while only one is being recorded.

Although a good analogy, the above is an example of a unidirectional payment channel many are familiar with in the real world. A payment channel anchored into a blockchain would allow for a bi-directional payment channel in which both participants can send money to each other without broadcasting those transactions to the main blockchain.

Let’s jump back to the example we started with. Our participants may have started with 5 bitcoin each, but after a series of transactions the state of the channel has changed many times. For this example’s sake let’s say given the transaction history of the channel, the channel’s most recent state or distribution of funds is 8 bitcoin for one party and 2 bitcoin for the other party. If they wish to close the channel, one of the parties needs to broadcast only the very last state of the payment channel. In this case, after the channel state has been broadcast to the Bitcoin blockchain one party would receive 8 bitcoin and the other would be entitled to 2 bitcoin. There could have been thousands of transactions between the two parties but the Bitcoin blockchain only needed to know about and record a couple transactions.

However, there’s a minor problem with this set up: What if the other party is dishonest and wants to cheat by broadcasting a previous state that benefits them at the expense of the honest party?

Hashed Time-Lock Contracts (HTLCs)

If the party with 2 bitcoin, based on the latest channel state, broadcasts an old state of the channel that gives them all 10 bitcoin, the other party in the channel has time to broadcast the actual latest state to the Bitcoin blockchain.

The channel has a time-lock attached to it that makes the Bitcoin, or transaction outputs associated with the channel un-spendable until a certain amount of time has passed. The channel is locked for the duration of this time,  with time usually being defined in these situations as block height.

If the honest party is able to broadcast the correct state before the time-lock expires, the Bitcoin blockchain will be able to recognize which broadcast was the latest state of the channel. The Bitcoin blockchain will penalize the cheating party by giving everything in the payment channel to the cheated party. In this case, the cheater will get 0 bitcoin and the honest party will receive 10 bitcoin instead of 8 for their troubles.

As you may have noticed, payment channels as described above, although pretty cool, are not enough on their own. Another technology is needed to connect isolated payment channels in a way that creates a payment network.

By using bitcoin multi-signature contracts, and more specifically hash-locks and time-locks, Lightning developers have created a network of these payment channels in which parties do not have to have a direct connection to a channel to send a payment to it, nor do they have to trust others on the network.

We described time-locks earlier, but have since introduced a new lock called a hash-lock. A hash-lock restricts the spending of a transaction output like a time lock but instead of the passage of time making the outputs spendable, a specified piece of data needs to be revealed for the output to become spendable.

Hashed time-lock contracts (HTLCs) are the key connecting technology that makes use of these locks and essentially make Lightning a network of payment channels. HTLCs use hash-locks and time-locks in combination to create conditional payments based on the revelation of certain data (hash-locks) and the passage of time (time-locks). HTLCs allow users to make one payment conditional upon another, so payments can be routed across untrusted parties using a series of transactions with decrementing timeout values. If certain data is not revealed in the specified amount of time, the routing of payments between channels won’t be completed. If certain data is revealed in a specified amount of time by all nodes in the route, the payment will be successfully routed.

The delivery of funds by intermediate nodes to a recipient is achieved through a process of chained obligation. Intermediate nodes are permitted to accept funds ONLY if they have already forwarded the appropriate amount to the next node in the route AND have revealed the appropriate data in the appropriate amount of time. HTLCs demonstrate the possibilities of programmable money.

Lightning Network developers have produced a full explanation and visualization of the mechanics of these HTLC based payments which I’ve included below:

To illustrate how this process works, suppose Alice has a channel with Bob, who has a channel with Carol, who has a channel with Dave: A<->B<->C<->D. How can Alice pay Dave?

Alice first notifies Dave that she wants to send him some money. In order for Dave to accept this payment, he must generate a random number R. He keeps R secret, but hashes it and gives the hash H to Alice.

Dave gives hash H to Alice

Alice tells Bob: “I will give Bob a signed tx that pays him if he can provide R also known as the preimage of H within 3 days.” In particular, she signs a transaction where for the first three days after it is broadcast, only Bob can redeem it with knowledge of R, and afterwards it is redeemable also by Alice. This transaction is called a Hash Time-Locked Contract (HTLC) and allows Alice to make a conditional promise to Bob while ensuring that her funds will not be accidentally burned if Bob never learns what R is. She gives this signed transaction to Bob, but neither of them broadcast it, because they are expecting to clear it out later.

Alice creates HTLC with Bob

Bob, knowing that he can pull funds from Alice if he knows R, now has no issue telling Carol: “I will pay you if you can produce the preimage of H within 2 days.”

Carol does the same, making an HTLC that will pay Dave if Dave can produce R within 1 day. However, Dave does in fact know R. Because Dave is able to pull the desired amount from Carol, Dave can consider the payment from Alice completed. Now, he has no problem telling R to Carol and Bob so that they are able to collect their funds as well.

Dave distributes R

Now, everyone can clear out, because they have a guaranteed way to pull their deserved funds by broadcasting these HTLCs onto Bitcoin’s network (i.e. on-chain). They would prefer not to do that though, since broadcasting on-chain is more expensive, and instead settle each of these hops off chain. Alice knows that Bob can pull funds from her since he has R, so she tells Bob: “I’ll pay you, regardless of R, and in doing so we’ll terminate the HTLC so we can forget about R.” Bob does the same with Carol, and Carol with Dave.

Everyone terminates their HTLCs


Now, what if Dave is uncooperative and refuses to give R to Bob and Carol? Note that Dave must broadcast the transaction from Carol within 1 day, and in doing so must reveal R in order to redeem the funds. Bob and Carol can simply look at the blockchain to determine what R is and settle off-chain as well.”

Lightning developers have shown through the diagrams above “how to make a payment across the Lightning Network using only off-chain transactions, without requiring direct channel links or trusting any intermediaries. As long as there is a path from the payer to the payee, payments can be routed, just like the Internet.”

Outstanding Difficulties

Receiving Lightning payments can be quite difficult at first, making the onboarding process for interested individuals and merchants much more complex than receiving on-chain blockchain payments.

There are a few conditions that need to be met to receive Lightning payments:

  1. A user must send some payments out of their channel to create room for incoming payments. For example if you fund a channel with 1 BTC AND the other side of the channel does not commit funds, you will not be able to receive any payments from other nodes on the network. Your channel is essentially “full”. To make room for payments you would have to spend some of that BTC and get it out of your channel or the other party would have to add funds to the channel to make room for incoming payments.
  2. Users have to create a payment request for every incoming payment.
  3. User wallets have be online to receive Lightning payments.

The third condition is a difficulty all on its own. Everyone on the Lightning Network has to stay online at all times for them to interact with the network. This isn’t true of the Bitcoin blockchain. Users of the Bitcoin blockchain can come on and offline as they please without a decrease in usability. There are even ways of sending and receiving Bitcoin without the internet at all. Users can now use certain mesh networks, satellites, and even radio. Currently there are no solutions we know of that allow users to use the Lightning Network effectively without an always on node. This may change, but as of now we haven’t seen a solution that resolves this or minimizes this condition. If you do know of one please let us know.

In addition, if Lightning nodes that are online have a catastrophic failure, node operators currently need to restore their channel’s funds with a mnemonic seed AND the last channel state. If they don’t back up their channel states, their funds will be unrecoverable. The seed by itself isn’t enough. Currently there is a proposal that addresses this and is slated to be merged into the next release of the Lightning Network daemon.

Another difficulty will be routing medium to large payments through Lightning. Many Lightning developers see the network overcoming this limitation, but in the current moment Lightning is best for micro and small transactions. However, as the network progresses many will want to send medium to high value transactions without the possibility of a routing failure. Being able to route larger payments is near impossible currently, but not inconceivable in the future. A lot depends on how much liquidity is staked throughout the network, the price of Bitcoin, and how routing develops overtime.

The lightning network needs a decent amount of liquidity dispersed throughout the network to be able to route larger payments reliably. This need presents some centralization risk. Large pools of liquidity and expertise will probably need to form to make large payments reliably routable. Large node operators will have to become adept at rebalancing channels, monitoring of channels, analyzing network topology, and setting fees.

These large pools of liquidity will probably benefit from economies of scale, much like PoW mining does, leading to the relative centralization of the network. These hypothetical large pools of liquidity would be similar to tier 1 providers of the internet or the correspondent banking network who benefit from economies of scale. Currently only sixteen tier 1 providers exist and only a handful of banks in each jurisdiction act as correspondent banks. Depending on your point of view these networks could be decentralized enough or too centralized. We believe decentralization is incredibly hard to define in a precise manner and isn’t an end in of itself.

Improvements to the Network

A key part of making Lightning work is punishing cheaters and incentivizing honest behavior. To help out with this, third parties known as “watchtowers” will be used to focus on monitoring the behavior of channels, their states, and the underlying blockchain the channels are anchored to.

Watch-towers will determine whether or not a party in an LN channel has improperly broadcast a prior channel state. Node operators can do this on their own, but outsourcing this focus could bring even more safety and security to the network. Mistakes and bugs do happen and operators may find it useful to outsource some monitoring to third parties.

Another potential issue related to punishment is the issue of good-faith parties accidentally broadcasting a prior channel state and subsequently being punished for it. A proposal called El-too has been put forward as a possible solution. El-too would make it impossible to settle a channel on-chain with outdated channel states. El-too only allows agreed upon states to be settled. Unfortunately a small improvement would have to implemented in Bitcoin itself via a soft fork to make El-too work.This could take some time.

And lastly, to address the issue of routing medium and large payments over the network, a couple of Lightning developers have developed a protocol called Atomic Multi-Path Payments (AMP). AMP would allow a sender to atomically split a large payment flow amongst several smaller individual payment flows.

The AMP proposal is very similar in spirit to how the internet works today. By breaking up data into infinitely small chunks users of the internet can stream data bit by bit instead of forcing a giant blob of data through a pipe it can’t fit through. The AMP proposal might enable the possibility of streaming money like data is streamed over the internet. Lightning can’t handle large payments now but could stream large payments in the not too distant future.

Closing Remarks

The Lightning Network, like Bitcoin, began as an idea on a white-paper and quickly evolved into a project supported by hundreds of developers, dozens of companies, with thousands of contributing nodes on its network. It has been fascinating for us to watch its rapid development and the enthusiasm of its supporters. We are actively looking at ways to enable an easy to use and non-custodial Lightning experience for our users.

We look forward to the continued development of the network and protocol.

Be the first to get updates from Edge by signing up for our newsletter at the bottom right corner of our website and if you haven’t yet, download the Edge Wallet on iOS or Android.




    Permission.io retargeting pixel Skip to content