A Beginner's Guide to Lightning Network Bitcoin

Key Points

• Layer 2 solutions were created to address scalability limitations inherent in blockchain technology.

• Lightning Network is a Layer 2 scaling solution that offers fast transactions without block confirmation, enabling efficient micropayments.

• It provides secure and scalable payments through multisig addresses and Hash Timelock Contracts.

Introduction

Cryptocurrencies possess some remarkably unique properties. They cannot be easily hacked or shut down, and anyone can use them to transfer value globally without third-party interference.

To preserve these functionalities, significant compromises must be made. Since a cryptocurrency network is maintained by numerous nodes, throughput is limited. Consequently, the number of transactions per second (TPS) that a blockchain network can process is relatively modest for a technology aimed at mass adoption.

To overcome blockchain technology's limitations, various scaling solutions have been proposed to increase the number of transactions a network can handle. In this article, we will explore Lightning Network, one such extension to the Bitcoin protocol.

What is Lightning Network?

Lightning Network is a network operating atop the blockchain to facilitate fast peer-to-peer transactions. Bitcoin is no exception to this. Other cryptocurrencies have also integrated this solution.

You might wonder what we mean by "operating atop the blockchain." Lightning Network is what's known as an off-chain solution or a Layer 2 solution. It enables people to conduct transactions without needing to record each transaction on the blockchain.

Lightning Network is separate from the Bitcoin network—it has its own nodes and software, yet it interacts with the underlying blockchain. To enter or exit Lightning Network, one must create special transactions on the blockchain.

What you essentially do with your first transaction is create a kind of smart contract with another user. We'll delve into the details shortly, but for now, imagine a smart contract where a private ledger is maintained for you and the other user. You can record many transactions in this ledger. They are visible only to you and your counterparty, but neither of you can cheat the other due to how the setup is configured.

This mini-ledger is called a channel. Let's say Alice and Bob each deposit 5 BTC into a smart contract. Now they both have a balance of 5 BTC in their channel. Alice can write in the ledger "pay Bob 1 BTC". Now Bob has 6 BTC and Alice has 4. Then Bob can send 2 BTC back to Alice, updating the balance to 6 BTC on Alice's side and 4 BTC on Bob's side. They can continue doing this for some time.

At any moment, either party can publish the current state of the channel to the blockchain. At that point, the balances on each side of the channel will be distributed to the respective parties on the network.

As the name suggests, Lightning transactions execute instantaneously. There's no need to wait for block confirmation for payment—transactions can proceed as quickly as your internet connection allows.

Why is Lightning Network Needed?

So far, Lightning Network (or simply LN) appears to be the most sensible approach to scaling Bitcoin's blockchain. Coordinating changes in such a large ecosystem is not straightforward—there's a risk of hard forks and potentially catastrophic errors. When substantial amounts of money are at stake, experimenting is incredibly dangerous.

When you experiment off-chain, you gain far greater flexibility. If something goes wrong, it won't affect the actual Bitcoin network. Layer 2 solutions don't undermine any of the security principles that have sustained the protocol for over 15 years.

There's also no requirement to abandon the old way of doing things. On-chain transactions on the network continue to function normally for end users, but now they have the option to conduct off-chain transactions.

Using Lightning Network offers several advantages. We'll explore some of the primary ones below.

Scalability

Blocks in Bitcoin are created approximately every ten minutes and can contain a limited number of transactions. Block space is a scarce resource, so you must bid against other users to get your transaction included promptly. Miners care about being paid, so they'll prioritise transactions with higher fees.

If few users attempt to send funds simultaneously, this isn't a problem. You can set a low fee, and your transaction will likely be included in the next block. However, when too many users broadcast transactions at once, the average fee can rise significantly. There have been instances when it exceeded $10. During the 2017 bull market, fees surpassed $50. In the period around early 2021, the average Bitcoin transaction fee exceeded $60.

This might seem trivial for transactions moving thousands of dollars worth of Bitcoin, but for small payments it's unacceptable. Who wants to pay a $10 fee for a $3 coffee?

With Lightning Network, you still pay two fees—one to open a channel and another to close it. But you and your counterparty can conduct thousands of transactions for free once the channel is open. When you finish, you simply need to publish the final state to the blockchain.

Overall, if more users rely on off-chain solutions like Lightning Network, block space will be utilised more efficiently. Small but frequent transfers can occur within payment channels, while block space is reserved for larger transactions and channel opening/closing. This would make the system accessible to a far broader user base, enabling long-term scalability.

Micropayments

The minimum amount of Bitcoin you can send in a transaction is approximately 0.00000546 BTC. At typical valuations, this equals roughly 38 cents. Though a small sum, Lightning Network allows you to push the boundaries to enable transactions with the smallest available unit—0.00000001 BTC, or one satoshi.

Lightning is far more appealing for micropayments. Regular transaction fees make it impractical to send tiny amounts to the main blockchain. However, within a channel, you can send a fraction of Bitcoin for free.

Micropayments are suitable for many use cases. Some users propose they could become a viable alternative to subscription-based models, where users instead pay small amounts each time they use a service.

Privacy

Another advantage of Lightning Network is the high level of privacy it can offer users. Parties don't need to announce their channels to the wider network. Although you can examine the blockchain and say that this transaction opened a channel, you cannot determine what happens inside it. If participants choose to keep their channel private, only they will know which transactions occur within it.

If Alice has a channel with Bob, and Bob has a channel with Carol, Alice and Carol can send payments to each other through Bob. If Dan is connected to Carol, Alice can send payments to him. You can imagine how this expands into a branching network of interconnected payment channels. In such a scenario, you cannot be certain who Alice sent funds to after the channel closes.

How Does Lightning Network Work?

We've explained how Lightning Network uses channels between nodes at a high level. Let's examine how the system operates internally.

Multisig Addresses

A multisig address (or multisignature address) is an address requiring multiple private keys to authorise a transfer. When creating one, you specify how many private keys can spend funds and how many of those keys are needed to sign a transaction. For example, a "1 of 5" scheme means five keys can create a valid signature and only one is needed to execute a transfer. A 2 of 3 scheme would mean that of three possible keys, any two are required to move funds.

To initialise a Lightning channel, participants lock funds using a 2 of 2 scheme. There are only two private keys that can sign, and both are required to move coins. Let's return to our friends Alice and Bob. Over the coming months, they'll be making many payments to each other, so they decide to open a Lightning Network channel.

This begins with both of them depositing, say, 3 BTC each to a shared multisig address. It's worth repeating that Bob cannot transfer funds from the address without Alice's consent, or vice versa.

This is equivalent to having a piece of paper that tracks each party's balance. Both start with a 3 BTC balance. If Alice wants to pay Bob 1 BTC, why not simply note that Alice now holds 2 BTC and Bob holds 4 BTC? Balances could be tracked this way until they decide to withdraw funds.

This is possible, but what's the problem? More importantly, wouldn't such simplicity give someone reason to stop cooperating? If Alice receives 6 BTC and Bob receives none, Bob loses nothing by refusing to transfer funds (except his friendship with Alice).

Hash Timelock Contracts (HTLC)

The system described above is simple and offers limited functionality compared to more sophisticated configurations. Things become far more interesting when we introduce a mechanism that ensures a "contract" between Alice and Bob. This involves the ability to recover funds from the channel if one party refuses to play by the rules.

This mechanism is called a Hash Timelock Contract (or HTLC). The term might sound complex, but the concept is actually quite straightforward. It combines two other technologies (hash-lock and time-lock) to eliminate the possibility of dishonest behaviour in payment channels.

A hash-lock is a condition on a transaction whereby funds can only be spent if you know a secret. The sender hashes some data and includes the hash in the transaction for the recipient. The only way the recipient can unlock it is by providing the original data (the secret) that matches the given hash. The only way to provide this data is to receive it from the sender.

A time-lock is a condition that prevents funds from being spent until a certain time. The time period is specified as an actual time or block height.

HTLCs are created by combining hash-locks and time-locks. In practice, HTLCs can be used to create conditional payments—the recipient must provide a secret by a certain time, or the sender can recover the funds. The next part is probably best explained with an example, so let's return to Alice and Bob.

Opening and Closing Channels

Consider this scenario: Alice and Bob have just created transactions that fund a multisig address. They plan to use this address in the near future, but for now these transactions haven't been published to the blockchain! First, one more thing needs to happen.

Remember that the only way to get these coins out of the multisig wallet is if Alice and Bob jointly sign a transaction. If Alice wants to send all six coins to an external address, she'll need Bob's approval. First, she creates a transaction (specifying an amount of six Bitcoin being sent to another address) and adds her own signature.

Alice could immediately try to broadcast the transaction, but it would be invalid because Bob hasn't added his signature. Alice must provide him with the incomplete agreement. Once he signs it, the transaction becomes valid.

However, in this case, there's currently no process requiring participants to act honestly. As we mentioned earlier, if your counterparty refuses to cooperate, your funds effectively become trapped. Let's move to the mechanism that prevents this. Several key elements will form the solution to this problem.

To avoid such an unfavourable situation, each party must devise a secret, let's call them: As and Bs. If Alice and Bob reveal them, they'll lose their funds, so they keep them secret for now. The pair then generates hashes of the respective secrets: h(As) and h(Bs). Thus, instead of sharing their secrets, they exchange hashes.

Alice and Bob also need to create a set of commitment transactions before they publish their first deposits to the multisig address. This involves certain security measures in case someone decides to hold funds "hostage".

If you think of a channel as a mini-ledger, as we referred to earlier, then commitment transactions are updates you make to the ledger. Each time you create a new pair of commitment transactions, you rebalance funds between the two participants.

In Alice's case, she'll have two outputs: the first address is her personal one, which she has funded, and the second, tied to a new multisig address. She signs this and passes it to Bob.

Bob does the same: one address is his personal one, and the other is multisig. He signs it and passes it to Alice.

Normally Alice could add her signature to Bob's transaction to make it valid. But you'll notice that these funds are being spent from a multisig using a "2 of 2" scheme, which hasn't been funded yet. It's like trying to cash a cheque with a zero balance. Therefore, these partially signed transactions can only be used after the multisig is activated.

The new multisig addresses (to which 3 BTC outputs are designated) have certain specific properties. Let's look at the incomplete transaction Alice signed and passed to Bob. The multisig-based output can be executed if the following conditions are met:

1. Both parties realise a joint signature.

2. Bob makes a transfer independently after a certain period of time expires (due to the time-lock).

3. Alice gains the ability to spend the balance if she learns Bob's secret: B.

For Bob's transaction, he asks Alice to realise the following:

1. Both parties realise a joint signature.

2. Alice makes a transfer independently after a certain period of time expires.

3. Bob gains the ability to spend the balance if he learns Alice's secret: A.

Note that neither party knows the other's secret, so point 3 is not yet possible. It should also be noted that if you sign the transaction, your counterparty can immediately spend the money, since there are no special conditions for their output. You can wait for the time to pass to spend the funds yourself, or you can cooperate with the other party to spend them completely.

Excellent! Now you can publish transactions to the original multisig address using the "2-2" scheme. At this stage, it's safe because you can recover your funds if your counterparty abandons the channel.

After the transaction confirms, the channel begins processing operations. This first pair of transactions shows us the current state of the mini-ledger. At this point, payouts will be distributed as follows: 3 BTC to Bob and 3 BTC to Alice.

When Alice wants to make a new payment to Bob, the pair will need to create two new transactions to replace the first set. The practice remains the same: agreements are signed only halfway. However, Alice and Bob will need to abandon their old secrets and exchange new hashes for the next round of transactions.

Either party can at any time sign and pass the latest transactions to the other to execute a "settlement", meaning to lock the final information onto the blockchain. Whoever does this will need to wait for the time-lock to expire, while the other party can spend the funds immediately upon receipt. It's worth noting that if Bob signs and broadcasts a transaction to Alice, she gains the ability to exit without any additional conditions.

Both parties can agree to close the channel together (cooperative channel closure). This is probably the simplest and fastest way to return your funds to the network. However, even if one party stops responding or refuses to cooperate, the other can still recover their funds after the time-lock expires.

How Does Lightning Network Prevent Fraud?

You may have already identified a possible attack vector. If Bob now has a balance of 1 BTC, what prevents him from broadcasting an older transaction when he had more coins? He already has Alice's signature, and all he needs is to add his signature and broadcast the transaction to the blockchain, right?

Nothing stops him from doing so, except that he could lose his entire balance. Suppose he decides to do this and broadcasts his old transaction, which transfers 1 coin to Alice while 5 go to the multisig address we mentioned earlier.

Alice receives one coin immediately. Bob must wait for the time-lock to expire before he can spend the multisig address balance. Remember the condition mentioned earlier that would allow Alice to spend those same funds immediately? She needs the secret she didn't have then. She can do so from the moment the second round of transactions was created, as Bob passed her this secret.

While Bob waits for the time-lock to expire and can do nothing, Alice can move those funds. This sanction-based mechanism ensures that a participant is unlikely to attempt fraud, for the simple reason that if they do, the other party immediately gains access to their shared coins.

Payment Routing

We touched on this earlier: channels can connect with each other. Otherwise, Lightning Network wouldn't be so useful for payments. After all, you're not going to lock $500 in a channel with a café just to get your daily coffee fix over the next few months, right?

You don't have to. If Alice opens a channel with Bob, and he has a channel with Carol, Bob gets the ability to send payments using the connection between them. This mechanism works in several "hops", meaning Alice can quickly transfer funds to anyone for whom such a path exists.

For their role in routing, intermediaries can charge a small fee (not necessarily). Since Lightning Network is a relatively new concept, the fee market hasn't fully formed yet. Many expect to see fees based on the liquidity provided.

On the base blockchain, your fee depends on what position your transaction occupies in the block. The transaction amount doesn't matter: transfers from $1 to $10,000,000 will have the same fee. By comparison, Lightning Network has no concept of position in a block.

Instead, there's the idea of local and remote balances. Local balance is the amount you can "push" to the other end of the channel, while remote balance is the balance your counterparty can provide to you.

Let's consider another example. Let's look more closely at one of the paths mentioned above: Alice <> Carol <> Frank.

User balances before and after transferring 0.3 BTC from Alice to Frank.

Alice <> Carol and Carol <> Frank have a combined capacity of 1 BTC. Alice's local balance is 0.7 BTC. If they decided to settle now and display the latest information on the blockchain, Alice would receive 0.7 BTC and Carol her remote balance (that is, 0.3 BTC).

If Alice wants to send 0.3 BTC to Frank, she sends 0.3 BTC to Carol. Carol then withdraws 0.3 BTC from her local balance in the channel with Frank. As a result, Carol's balance remains the same: +0.3 BTC from Alice and -0.3 BTC to Frank, which cancel each other out.

Carol loses nothing by acting as a link between Alice and Frank, but she makes herself less flexible. As you can see, she can now spend 0.6 BTC in her channel with Alice and only 0.1 BTC in the channel with Frank.

You can imagine a scenario where Alice is connected only to Carol, and Frank to a much wider network. Previously, Carol could send a total of 0.4 BTC to other participants through Frank, but now she can only offer 0.1 BTC because all her funds are on the other end of the channel.

In this scenario, Alice effectively consumes Carol's liquidity. Without any incentive, Carol may not want to continue weakening her own position. Instead, she might simply say: I'll route each 0.01 BTC for a fee of ten satoshis. Thus, the more local balances utilise Carol's services on "stronger" paths, the more profitable her position becomes.

We mentioned earlier that there are no actual fee requirements. Some users may not care about reduced liquidity. Other users might simply open channels exclusively for receiving.

Lightning Network Limitations

It would be wonderful if Lightning Network solved all of Bitcoin's scalability problems. Unfortunately, the concept has its drawbacks that may prevent this.

User Experience

Bitcoin is not a very intuitive system for beginners: addresses, fees, and other aspects can be confusing during a user's first experience. After setting up a Lightning client, users also need to start opening channels before they can make payments. This can take considerable time and will likely be challenging for newcomers, as it requires familiarity with numerous terms, including inbound and outbound capacity.

Nevertheless, technologies continually improve, lowering the barrier to entry and providing a more streamlined user experience.

Liquidity

One critical concern about Lightning Network is that your ability to conduct transactions may be limited. You cannot spend more than what's locked in your channel. If all funds are distributed across remote balances, you'll likely need to close the channel. Alternatively, you could wait for someone to pay you, but this isn't an ideal solution.

Your routes may be constrained by the overall capacity of the channels. Look at our earlier example: Alice <> Carol <> Frank. If the Alice-Carol channel has 5 BTC and the Carol-Frank channel only 1 BTC, Alice can never send more than 1 BTC through them. Even then, all the balance must be on the Carol <> Frank channel side for this to work. This limitation can seriously restrict the amount of funds flowing directly through LN channels, directly affecting usability.

Centralised Hubs

Because of the problem mentioned in the previous section, there's concern that the network will encourage the development of large "hubs". This involves the emergence of tightly connected organisations with substantial liquidity. Any significant payments would need to be routed through some of these organisations.

Clearly, this isn't the ideal situation. It would weaken the system, as these providers going offline would cause significant disruption to node relationships. There's also an increased risk of censorship due to the presence of several points through which transactions pass.

Current Stage of Lightning Network Development

As of early 2024, Lightning Network demonstrates solid development. The network comprises over 13,000 nodes online, more than 52,000 active channels, and slightly over 4,570 BTC in circulation.

There are several different node implementations. The most popular are c-lightning by Blockstream, Lightning Network Daemon by Lightning Labs, and Eclair by ACINQ. For users not inclined toward technically demanding approaches, many companies offer Plug-and-Play nodes. In such cases, all you need to do is switch on the device. After that, you'll be ready to work with Lightning Network.

Summary

Since the mainnet launch in 2018, Lightning Network has experienced significant growth. At this stage of development, there are some limitations in user experience, such as requiring some technical competency to run a Lightning node. However, as the technology evolves, we'll observe a reduction in the barrier to entry.

FAQ

什么是比特币闪电网络？它解决了什么问题？

比特币闪电网络是第二层解决方案，通过链下操作实现快速、低成本交易。它解决了比特币网络的可扩展性问题，减少主链拥堵，提高交易速度和降低交易额。

闪电网络与比特币主网有什么区别？

比特币主网安全性高但交易速度慢、手续费高；闪电网络是二层支付通道，交易速度快、手续费低，但需要主网作为结算基础。两者互补，共同构建比特币生态。

闪电网络是如何工作的？支付通道的原理是什么？

闪电网络通过在用户间建立支付通道实现链下交易。双方锁定资金创建通道，可进行无限次快速交易，最后将余额结算到比特币主网。支付通道利用智能合约确保交易安全，无需每笔交易上链。

如何在闪电网络上进行交易？需要哪些工具或钱包？

下载闪电网络钱包（如Blue Wallet、Muun），用比特币充值后即可创建支付通道。通过链接节点，可快速进行微额交易，手续费极低，无需等待区块确认。

闪电网络上交易安全吗？有哪些风险需要注意？

闪电网络交易采用端到端加密，安全性较高。主要风险包括：交易对手方风险、流动性风险、技术实现风险。但通过惩罚机制，对手方广播过时交易需承担巨大风险，整体安全性可靠。

闪电网络相比其他第二层解决方案有什么优势？

闪电网络为比特币提供更高交易速度和极低费用，通过状态通道技术实现即时支付，同时继承L1安全性。相比其他L2方案，闪电网络更轻量、更私密、交易额处理能力更强。

Як новачку почати користуватися мережею Lightning Network? Скільки коштів потрібно?

Почніть із завантаження гаманця Lightning Network. Мінімальна сума залежить від провайдера, але можна стартувати від 0,001 BTC. Відкрийте канал, депозит коштів і розпочніть миттєві транзакції з низькими комісіями.