Everything About the Bitcoin Lightning Network

The Bitcoin network has the advantage of being safe and highly secure. For more than 10 years, the Bitcoin network has never been hacked and has never once stopped running. This is because nodes around the world protect the network through mining, using proof of work.

However, because of these same traits, the Bitcoin network has the drawbacks of very slow transaction processing and expensive fees. The Lightning Network emerged as a solution to these problems.

What Is the Lightning Network?

The Bitcoin Lightning Network is a separate network built on top of the Bitcoin blockchain so that bitcoin can be transacted cheaply and quickly. Besides Bitcoin, other crypto assets such as Litecoin have also built and offer their own Lightning Networks.

What does it mean that the Lightning Network sits on top of a blockchain? The Lightning Network is also called an off-chain solution or a Layer 2 solution. It allows fast transactions without recording every single transaction on the blockchain.

Features of the Lightning Network

Transactions within the Lightning Network are very fast. There's no need to wait for block confirmations on the Bitcoin blockchain.

The Lightning Network is separate from the Bitcoin network. It has its own nodes and software, but ultimately communicates with the main chain. To enter or exit the Lightning Network, you need to create a special transaction on the blockchain.

How the Lightning Network Is Implemented

To use the Lightning Network, you need to set up a smart contract with another user. I'll explain the details below, but for now, just think of it as a private ledger between you and the other user being recorded in the smart contract.

This ledger on top of the smart contract is called a mini-ledger channel. Only the parties involved can see the records in a mini-ledger channel, and it can record many transactions. However, thanks to a few unique features, it's impossible to cheat the other party.

A Lightning Network Example

Let's say Changpeng and Justin each deposit 5 BTC into a Lightning Network mini-ledger using a smart contract. Now their channel shows a balance of 5 BTC each. That night, Changpeng can send 1 BTC to Justin. Now Changpeng holds 4 BTC and Justin holds 6 BTC. Next, Justin can send 3 BTC to Changpeng. Changpeng now holds 7 BTC and Justin holds 3 BTC.

The two can keep doing this as long as they like. Once all their transactions are done, they can send the mini-ledger to the Bitcoin blockchain network and record the transaction. This way, all of their dealings are recorded on the blockchain network as just a single transaction.

4 Benefits of the Lightning Network

The Lightning Network can speed up transactions and save on fees. Another benefit of the Lightning Network is that it can safely scale the Bitcoin network while keeping it intact.

Coordinating changes in a large ecosystem is not easy, and it comes with the risk of hard forks and critical bugs. With the Lightning Network, you can achieve flexibility and scalability through a Layer 2 solution while keeping the existing Bitcoin ecosystem as it is.

1. Scalability

A Bitcoin block is created roughly every 10 minutes and can record only a limited number of transactions. Since each block has limited space, there's fierce competition among those sending transactions. Because miners care most about earning rewards, they process the transactions that pay the highest fees first.

This isn't a problem if not many people are trying to send bitcoin at the same time. But if every user sends transactions at once, the average fee can rise sharply. During the 2017 bull market, Bitcoin transaction fees even exceeded $50.

When you're sending thousands of dollars' worth of bitcoin, this might not seem like a big deal. But what about small payments? No one wants to pay a $5 fee to buy a coffee at Starbucks.

On the Lightning Network, you pay transaction fees only twice in total: once to open a channel and once to close it. But while the channel is open, you can make thousands of transactions for free. Once you're done transacting, you simply send the final state to the blockchain.

If more users use off-chain solutions like the Lightning Network, block space will be used more efficiently. Small and frequent transfers can be handled in Lightning payment channels, while block space is used for large transactions and for opening/closing Lightning channels. This would make the Bitcoin system much more accessible to far more users, allowing the system to scale in the long run.

2. Micropayments

The minimum amount of bitcoin that can be used in a transfer is about 0.00000546 BTC. At the time of writing, that's worth about KRW 50. It's a small amount, but with the Lightning Network you can go beyond the limit of transacting only down to 0.00000001 BTC, or 1 satoshi, the smallest unit currently available. Lightning is far more effective for micropayments. Within a channel, you can send bitcoin almost for free.

3. Privacy

Another advantage of the Lightning Network is that it can offer users a high level of privacy. The blockchain only records the opening and closing of a channel; you can't see what happens inside it. If participants set a channel to private, only the parties involved know what transactions are taking place.

2 Core Technologies of the Lightning Network

The two core technologies of the Lightning Network are multisignature and hash time-locked contracts.

1. Multisignature

A multisignature address is an address that can be spent from by multiple private keys. When creating the address, you can specify how many private keys can spend the funds and how many keys are needed to sign a transaction. For example, a 1/5 scheme means 5 keys can produce a valid signature, and only one is needed. A 2/3 scheme means you only need 2 of the 3 possible keys to spend the funds.

For example, to start a Lightning channel, participants lock funds in a 2/2 scheme. There are only two private keys that can sign, and both are needed to move the coins. Let's bring back our friends Changpeng and Justin at this point. "Changpeng! Justin!" The two friends plan to make lots of payments to each other over the next few months, and they've decided to open a Lightning Network channel.

Each of them deposits 3 BTC into a jointly owned multisignature address. Changpeng can't move funds out of this address without Justin's consent, and vice versa.

Now the two keep a mini-ledger, a record of both sides' balances. The starting amount is 3 BTC each. If Changpeng wants to pay Justin 1 BTC, they just record that Changpeng now owns 2 BTC and Justin owns 4 BTC. They can track balances this way until they decide on the final state of the funds.

2. Hash Time-Locked Contracts (HTLC)

A hash time-locked contract is the mechanism that enforces the "contract" between Changpeng and Justin. It's a way for one party to still recover their funds from the channel even if the other party decides not to follow the rules.

The term hash time-locked contract (or HTLC) might sound difficult, but it's actually a fairly simple concept to understand. The HTLC mechanism combines two technologies (hashlocks and timelocks) to solve the trust problem in payment channels.

A hashlock is a condition applied to a transaction so that the funds can only be spent by proving you know a secret. The sender hashes a piece of data and includes the hash in the transaction sent to the recipient. The only way the recipient can spend the funds is by providing the original data (the secret) that matches the hash. And the only way the recipient can provide that data is if the sender gives it to them.

A timelock is a condition that prevents funds from being spent until a certain time. The condition can be set as a real-world time or a specified block height.

To sum up, a hash time-locked contract is created by combining a hashlock and a timelock. In practice, HTLCs can be used to create conditional payments: if the recipient doesn't provide the secret before a certain time, the sender can reclaim the funds. The next part may be easier to explain with an example, so let's go back to the story of Changpeng and Justin.

How to Open and Close a Lightning Channel (A Real Example)

Earlier, we saw the example where Changpeng and Justin created a transaction to fund the multisignature address they'll share. But that transaction hasn't been sent to the blockchain yet! There's one more thing to do.

There are Justin's 3 coins and Changpeng's 3 coins. The only way these coins can get through the multisig is if Changpeng and Justin jointly sign a transaction. If Changpeng wants to send all 6 coins to an outside address, he needs Justin's approval. Changpeng would first construct the transaction (send 6 bitcoin to this address) and add his own signature.

Changpeng could broadcast the transaction right away, but since it doesn't include Justin's signature, it would be invalid. Changpeng must first pass the incomplete transaction to Justin. Once Justin adds his signature, the transaction becomes valid.

However, there isn't yet a mechanism that makes everyone play honestly. So if the other party refuses to cooperate, the funds are effectively stuck. Let's look at the mechanism that prevents this. There are a few important elements.

Each party must create a secret. Let's call them A and B. The two will generate the hashes of their secrets, h(As) and h(Bs). So instead of sharing their secrets, they share these hashes with each other.

Changpeng and Justin also need to create a series of contract transactions before publishing the first transaction to the multisignature address. This protects them in case the other party tries to take control of the funds.

In the mini-ledger mentioned earlier, contract transactions are updates to the ledger. Each time a new pair of contract transactions is created, the funds are rebalanced between the two participants.

Changpeng's transaction includes one output paying to an address he owns and one locked to a new multisignature address. Changpeng signs it and passes it to Justin.

In the same way, Justin creates one output paying himself and another paying a different multisignature address. Justin signs it and passes it to Changpeng.

Normally, Changpeng could add his signature to Justin's transaction to make it valid. But notice that these funds are being spent from the 2/2 multisig that hasn't been funded yet. It's like trying to write a check from an account with a current balance of zero. So partially signed transactions like these can only be used after the multisig is funded.

The new multisig address (where the 3 BTC outputs go) has some special properties. Let's look at the incomplete transaction that Changpeng signed and passed to Justin. The multisig output can be spent under the following conditions.

1. Both parties can cooperate to sign.
2. Justin can spend it on his own after a certain amount of time has passed (due to the timelock).
3. Changpeng can spend it if he knows Justin's secret B.

Likewise, the transaction Justin passed to Changpeng has the following properties.

1. Both parties can cooperate to sign.
2. Changpeng can spend it on his own after a certain amount of time has passed.
3. Justin can spend it if he knows Changpeng's secret A.

Since neither side knows the other's secret, 3) isn't possible yet. Another thing to note is that once you sign the transaction, the other party can spend their funds right away with no special conditions. Finally, you can either wait for the timelock to expire before spending the funds, or cooperate with the other party to spend them immediately.

Great. Now the transaction can be safely sent to the original 2/2 multisignature address. Even if the other party doesn't sign, you can recover your funds, so you can transact safely.

Once the transaction is confirmed, the channel goes live. The first pair of transactions shows the current state of the mini-ledger. Right now, Justin has 3 BTC and Changpeng has 3 BTC.

Let's recap once more. If Changpeng wants to make a new payment to Justin, they create two new transactions to replace the first pair. The two transactions are identical and only half-signed. But first, Changpeng and Justin discard their old secrets and exchange new hashes for the next transactions.

Either party can, at any time they like, sign and broadcast one of the most recent transactions to request "settlement" on the blockchain. If the timelock expires, the funds become immediately spendable; or if Justin signs and broadcasts Changpeng's transaction, Changpeng can also spend his funds freely.

The two parties can also agree to close the channel together. This is probably the easiest and fastest way to get the funds back on-chain. Even if one party is unresponsive or refuses to cooperate, the other can wait out the timelock and recover their funds.

How Does the Lightning Network Prevent Cheating?

You may have spotted a possible attack in how the Lightning Network works. If Justin currently has a balance of 1 BTC, what stops him from broadcasting an older transaction in which he had a larger balance? Justin already received a half-signed transaction from Changpeng, so couldn't he just add his signature and broadcast it? Nothing stops this kind of cheating, except the fact that he could lose his entire balance.

Let's say Justin goes ahead and broadcasts the old transaction that pays 1 BTC to Changpeng and 5 BTC to the multisig address mentioned earlier. Changpeng receives his coins immediately. Justin, on the other hand, has to wait until the timelock expires before he can spend the funds from the multisig address. Remember the other condition we mentioned that lets Changpeng spend those same funds immediately? Changpeng needs a secret he didn't have at the time. But as soon as the second transaction was created, Justin revealed that secret to Changpeng.

While Justin can do nothing but wait for the timelock to expire, Changpeng can move those funds. So under this mechanism, even if Justin cheats, Changpeng can access those funds, which greatly lowers the chance that either party will try to cheat.

Routing Payments

Lightning channels can be linked together. Otherwise, the Lightning Network wouldn't be very useful for payments. It would be inefficient to lock $500 into a channel with a coffee shop just to buy coffee every day for the next few months.

If Changpeng opens a channel with Justin, and Justin already has a channel open with Carol, Justin can route payments between the two channels. This can work across multiple hops, so Changpeng can effectively pay anyone he has a route to.

Routing intermediaries can earn a small fee. Fees in the Lightning market haven't fully taken shape yet, but many expect them to be based on liquidity.

On an underlying base chain like the Bitcoin network, fees are determined by how much space a transaction takes up in a block, and the value being sent doesn't matter. A $1 payment and a $10,000,000 payment cost the same fee. The Lightning Network, on the other hand, has no concept like block space.

Instead, the Lightning Network has the concepts of local balance and remote balance. Your local balance is the amount you can send to the other end of the channel, and your remote balance is the amount the other party can send to you.

Let's take another example. Let's look closely at the route below: Changpeng <> Carol <> Frank.

The total available balance in Changpeng <> Carol and in Carol <> Frank is 1 BTC each. Changpeng's local balance is 0.7 BTC. If they settled on the blockchain now, Changpeng would receive 0.7 BTC and Carol would receive the remote balance (i.e., 0.3 BTC).

If Changpeng wants to send 0.3 BTC to Frank, Changpeng passes 0.3 BTC to Carol's side of the channel. Carol then passes 0.3 BTC from her local balance in her channel with Frank. As a result, Carol's balance stays the same: the +0.3 BTC she received from Changpeng and the -0.3 BTC she passed to Frank cancel each other out.

Carol doesn't lose any assets while acting as the connector between Changpeng and Frank, but she does give up liquidity. Now Carol can use 0.6 BTC in her channel with Changpeng, but only 0.1 BTC in her channel with Frank.

Imagine that Changpeng is connected only to Carol, while Frank is connected to a much wider network. Before, Carol could send a total of 0.4 BTC to others through Frank, but now she can only send 0.1 BTC, since that's all that's left in the channel.

In this scenario, Changpeng is eating into Carol's liquidity. Without a specific incentive, Carol wouldn't want to take part in this. So Changpeng could instead offer to pay a fee of 10 satoshis for every 0.01 BTC routed.

As mentioned earlier, there's actually no obligation to charge fees. Some people may not worry about reduced liquidity. A sender can also open a channel directly with the recipient.

3 Limitations of the Lightning Network

It would be great if the Lightning Network could solve all of Bitcoin's scalability problems. Unfortunately, though, the Lightning Network has the following 3 drawbacks.

1. Usability

Bitcoin isn't the most beginner-friendly system, and there's a lot to understand, such as addresses and fees. However, wallets can abstract away the complexity and give users features similar to traditional payment systems. You can download a smartphone wallet, receive some coins, and start using it right away.

That isn't possible on the Lightning Network right now. Generally, to fully use a Lightning node you need access to a Bitcoin node, and options for smartphone apps are limited.

After the client is set up, users have to open a channel before they can make payments. This can take a long time, and concepts like inbound/outbound capacity can be overwhelming for first-time users.

That said, improvements are continually being made to lower the barrier to entry and give users a more streamlined experience.

2. Liquidity

One of the biggest criticisms of the Lightning Network is that transaction limits are restricted. You can't spend more than the amount locked in the channel. If you've spent so much that the channel's funds have all moved to the remote balance, you have to close the channel. Alternatively, you could wait until someone else pays through the channel, but that's not a great option.

Routes can also be limited by the total capacity of channels. Let's use the earlier Changpeng <> Carol <> Frank example. If the channel between Changpeng and Carol has a capacity of 5 BTC but Carol and Frank's has only 1 BTC, Changpeng can't send more than 1 BTC. Even then, it only works if the entire balance of the Carol <> Frank channel is on Carol's side. This can limit how much money can be sent through Lightning Network channels and can affect usability.

3. Centralized Hubs

Because of the problems mentioned in the previous section, there are concerns that the network will lead to the creation of large "hubs". In other words, large entities that are rich in liquidity and closely connected to one another. Significant payments would have to go through some of these entities.

Of course, that's not a good situation. If a central entity goes offline, the relationships between participants would be thrown into chaos, which could weaken the system. And since transactions would pass through only a few points, the risk of censorship would also rise.

Where the Lightning Network Stands Today

As of March 2022, the Lightning Network is in healthy shape. The Lightning Network currently has more than 35,000 online nodes, more than 85,000 active channels, and a capacity of over 3,570 BTC.

Among node implementations, Blockstream's c-lightning, Lightning Labs' Lightning Network Daemon, and ACINQ's Eclair are the most popular. With these nodes, you can start using the Lightning Network as soon as you power on your device.

Wrapping Up

Many people still think the Lightning Network is only in its early days. But since its mainnet launch in 2018, the Lightning Network has grown significantly.

It's true that running a Lightning node requires technical knowledge, so there are still usability hurdles to overcome. But as development continues, the barrier to entry may come down over time.

If these problems are solved, the Lightning Network could become an essential part of the Bitcoin ecosystem, greatly improving scalability and transaction speed.