Cryptocurrencies have significant properties that make them less vulnerable to hacking or shutdowns. Cryptocurrencies allow everyone to transfer value globally without the need for a third party to intervene.
There is a huge price to pay to ensure that these characteristics remain the same. The throughput is limited due to the large number of nodes running the cryptocurrency. Therefore, while working towards mass adoption of the technology, the transactions per second (TPS) that the blockchain network can handle is relatively low.
To overcome the inherent limitations of blockchain technology, various scalability solutions have emerged to increase the number of transactions the network can process. In this article, we will dive into an extension of the Bitcoin protocol, the Lightning Network.
What is Lightning Network?
The Lightning Network runs on top of the blockchain and is designed to speed up peer-to -peer transactions. The use of the network is not limited to Bitcoin, and cryptocurrencies such as Litecoin are also integrated into it.
We may be confused, what does “on top of the blockchain” mean? Lightning Network is a so-called off- chain or Layer 2 solution. Individuals can transact through the network without having to record every transaction on the blockchain.
The Lightning Network is independent of the Bitcoin network and has autonomous nodes and software, but still needs to communicate with the main chain. To enter and exit the Lightning Network, a special transaction needs to be created in the blockchain.
An individual’s first transaction is actually creating a kind of smart contract with other users. We’ll go into details later. For now, let’s start by envisioning smart contracts as private ledgers shared with other users. Users can write multiple transactions in this ledger. These records are only visible to users and counterparties, and based on the characteristics of the settings, both parties cannot falsify.
This mini-ledger is called a ” channel “. For example, Alice and Bob each invest 5 BTC into the smart contract. They each have a balance of 5 BTC in their channels at the moment. Alice then writes to the ledger ” Pay Bob 1 BTC “. Now, Bob has 6 BTC and Alice has 4 BTC. Bob later sends 2 BTC back to Alice. After the balance update, Alice has 6 BTC and Bob has 4 BTC left. They can keep doing this for a while.
Any party can publish the current status of the channel to the blockchain at any time. At that time, the balances at both ends of the channel are allocated to their respective on-chain addresses.
As the name suggests, Lightning Deals are lightning fast. Pay quickly when your internet connection allows, without waiting for block confirmations.
Why is the Lightning Network necessary?
As of now, the Lightning Network (or “LN” for short) seems to be the most logical way to deal with the scalability of the Bitcoin blockchain. Coordinating change in such a large ecosystem is tricky because of the risks of hard forks and potentially catastrophic vulnerabilities. Securing huge amounts of value is a top priority, and experimentation is extremely dangerous.
More flexibility is necessary if experiments are to be removed from the blockchain. A slight error in this way will not have a substantial impact on the Bitcoin network. Layer 2 solutions do not undermine any security assumptions that have kept the protocol running for more than 10 years.
Moreover, there is no need to change the conventional operation. In this way, the on-chain transactions of end users will continue as usual, and now there are more options for off-chain transactions.
There are many benefits to using the Lightning Network. We will focus on the following points.
Scalability
Bitcoin blocks are created approximately every ten minutes and hold a limited number of transactions. Block space is a scarce resource, so users must bid against each other to ensure that their transactions are included in the block space in a timely manner. Miners are most concerned about getting paid, so they prioritize transactions with higher fees.
Assuming no multiple users are trying to send funds at the same time, this shouldn’t really be a problem. You can set the fee low so that the transaction may be included in the next block. However, when everyone publishes transactions at the same time, it causes the average fee to skyrocket, occasionally exceeding $5. At the height of the bull market in 2017, fees even topped $50.
That seems trivial for thousands of dollars worth of bitcoin transactions. But micropayments have struggled. Who wants to pay an extra $5 for a $3 cup of coffee?
There are still two fees for using the Lightning Network, the fees for opening and closing channels. Once the channel is opened, users and counterparties can conduct thousands of transactions for free. Once the transaction is complete, just publish the final state to the blockchain.
From a macro perspective, if more people choose off-chain solutions such as the Lightning Network, the efficiency of block space usage will increase. Small, high-frequency transfers are made through payment channels, while block space is used for large transactions and channel opening/closing. As a result, the number of user groups accessing the system increases, and the scalability and thus the long-term development.
Micropayment
Bitcoin has a minimum transaction amount of approximately 0.00000546 BTC. As of this writing, that’s about four cents worth. This is already a small amount, but the Lightning Network pushes the transaction limit even lower, at 0.00000001 BTC, or one satoshi, in the smallest unit currently available.
Lightning Network is more attractive for micropayments. Sending small amounts on the main chain is impractical at the cost of regular transactions. Within the channel, however, tiny fractions of bitcoin can be sent for free.
Micropayments are suitable for numerous use cases. Some predict that micropayments will become an effective alternative to the subscription service model, whereby users pay only a small amount for each service they use.
Privacy
The second benefit of the Lightning Network is a higher level of confidentiality of user information. All parties do not need to spread their own channel information on the network. ” The transaction opens a channel ” may appear in the blockchain, but the details of the transaction will not be disclosed. If a participant chooses to make the channel private, the transaction progress is only visible to them.
Assuming Alice and Bob share a channel, and Bob shares another channel with Carol, Alice and Carol can send payments to each other through Bob. If Dan establishes a connection with Carol, Alice can also send him a payment. Just imagine extending this model to a vast network of interconnected payment channels. With this setup, as long as the channel is closed, there is no way to determine to whom exactly Alice sent the funds.
How does the Lightning Network work?
We’ve explained how the Lightning Network relies on channels from high-level nodes. Now let’s study the underlying specific principles.
Multi-signature address
A multisignature (or “multisig” for short) is an address that can be paid by multiple private keys. After users create a multisig, they can specify the number of private keys needed to pay funds and sign transactions. For example, a 1 out of 5 scheme means that five keys generate a valid signature, and only one key is needed to sign a transaction. The 3 out of 2 scheme means that if there are three keys, two of them are required to pay the fee.
To provision a Lightning Network channel, participants need to lock funds in a 2-for-2 scheme, which requires only two private keys to sign transactions, and two private keys are also required to transfer tokens. Let’s go back to the Alice and Bob example. Over the next few months, they will be paying each other a lot of money, so they decided to open a Lightning Network channel.
First, they each deposited 3 BTC in a shared multi-signature address. It is important to emphasize that Bob cannot transfer funds out of the address without Alice’s consent, and vice versa.
They only need to leave a piece of paper when adjusting the balance on both sides. Both parties each have an initial balance of 3 BTC. If Alice wants to pay Bob 1 BTC, why not just write down Alice’s existing 2 BTC and Bob’s balance of 4 BTC? This way the record can be traced back to the balance before deciding to actually transfer the asset out.
This approach works, but what’s the magic behind it? In fact, more importantly, does this make it easy to cooperate with each other? Assuming Alice ends up with 6 BTC and Bob has nothing, then Bob has nothing to lose by refusing to release the funds (maybe all he loses is his friendship with Alice).
Hash Time Lock Contract (HTLC)
The above system is boring and monotonous and nothing compared to the current trusted setup. Much more interesting is the mechanism we introduce next that enforces the “contract” between Alice and Bob. If one party does not play by the rules, the other party can take remedial action and withdraw funds from the channel.
This mechanism is called a ” Hash Time Lock Contract “, or “HTLC” for short. This term sounds daunting, but it’s actually a very simple and easy to understand concept. It combines the two technologies of hash lock and time lock, and takes remedial measures for various uncooperative operations in the payment channel.
The hash lock is a condition added to the transaction, and it is necessary to prove that you know a secret before you can use the funds. The sender hashes a piece of data and sends a transaction with the hash value to the receiver. The recipient can only use the funds by providing the initial data (i.e. the secret) that matches the hash. The only way to get this data is to be informed by the sender.
A time lock is a restriction that prevents funds from being used before a specific time, which can be specified at a specific time, or at a specific block height.
Hash Timelock Contracts (HTLCs) are created by combining hashlocks and timelocks. In practice, Hash Time Lock Contracts (HTLC) can be used to create conditional payments, that is, the receiver must provide a secret before a certain time, otherwise the sender will get the funds back. The following explanation with examples will make it easier to understand. So, let’s go back to Alice and Bob.
Open and close channels
We gave an example earlier, imagine that Alice and Bob have just created a transaction and deposited funds to a shared multi-signature address. But these transactions have not been published on the blockchain yet! We need to do one thing first.
Remember, the only way to get these tokens out of multisig is for Alice and Bob to co-sign the transaction. If Alice wants to send all six coins to an external address, she needs Bob’s approval. She initiates a transaction, specifying ” send six bitcoins to this address,” and then adds her own signature.
If she tries to publish the transaction immediately without Bob’s signature in it, the transaction is invalid. Alice must first hand over the incomplete transaction to Bob. After he signs it, the transaction takes effect.
So far, we have not established a mechanism to urge everyone to trade honestly. As mentioned earlier, if counterparties refuse to cooperate, funds are completely trapped. Let’s take a look at the mechanisms that prevent such situations. This mechanism involves multiple steps, please be patient and listen to our introduction one by one.
Each side provides a secret, which we call “As” and “Bs”. Once the two sides reveal the secret, the result is unimaginable. Therefore, they have to keep it a secret for now. The two secrets generate their own secret hashes, h(As) and h(Bs). This way both parties don’t need to share secrets, just share hashes with each other.
Before Alice and Bob publish their first transaction to the multi-signature address, they also need to create a series of commit transactions, a remedy that prevents the other from seizing funds.
If you think of a channel as the mini ledger we mentioned earlier, then a commit transaction is an update to the ledger. Every time a new set of committed transactions is created, the funds of the two participants are rebalanced.
Alice’s transaction has two outputs, one pays the address she owns, and the other locks into the new multisignature address. She signs it and hands it to Bob.
As in Bob’s case, one output pays itself and the other pays other multi-signature addresses. He signs it and hands it to Alice.
Typically, Alice can add a signature to Bob’s transaction to make the transaction valid. However, we note that these spending funds come from 2- for-2 multi sig that have not yet been allocated. This is similar to trying to pay a check from an account that currently has a zero balance. Therefore, these partially signed transactions can only be used once multisig is up and running.
The new multi-signature address, the destination for the 3 BTC output, has some properties. Let’s look at the incomplete transaction that Alice signed to Bob. Multi-signature outputs can be used under the following conditions:
- Both parties can cooperate to sign the transaction.
- Because of the time lock, Bob can spend himself after a period of time.
- Alice can use the funds if she knows Bob’s secret Bs.
For Bob’s transaction to Alice:
- Both parties can cooperate to sign the transaction.
- Alice can spend on her own after a period of time.
- If Bob knows Alice’s secret As, he can use the funds.
Remember that neither side knows each other’s secrets, so point 3 is temporarily out of reach. Another caveat is that if one party signs the transaction, the counterparty has immediate access to funds because their outputs are not subject to any conditions. Signatories need to wait until the timelock expires to spend the funds on their own, or directly co-spend with the other party.
all the best! Transactions can now be published to the initial 2 out of 2 multisignature address. This is safe because you can get your funds back if the counterparty abandons the channel.
After the transaction is confirmed, the channel will be up and running. The first pair of transactions shows the current state of the mini-ledger. At this point, the ledger pays 3 BTC to Bob, and also pays 3 BTC to Alice.
When Alice wants to make a new payment to Bob, the two create two new transactions to replace the first set of transactions. The operation is the same, the deal will be signed by each half. It’s just that Alice and Bob have to give up their old secrets and exchange new hashes for the next round of transactions.
Both parties can sign and publish the most recent transaction at any time and complete “settlement” on the blockchain. However, the signing party needs to wait for the time lock to expire, while the other party can spend the fee immediately. Remember, if Bob signs and publishes Alice’s transaction, she can have an unconditional output.
Both parties can reach a consensus and close the channel at the same time, that is, the cooperation is closed. This is the most convenient way for funds to return to the chain. However, if one party fails to respond or refuses to cooperate, the other party can recover the funds after the timelock expires.
How does Lightning Network prevent fraud?
We might notice the presence of attack vectors here. Assuming Bob’s existing balance is 1 BTC, how can I stop him from posting old transactions with a higher balance? After all, he already got the semi-signed transaction from Alice, and he just needs to add his own signature to publish it, right?
Nothing can stop him from doing this. But if he did, he could lose his entire balance. Suppose he does publish the old transaction, which pays Alice 1 coin and pays 5 coins to the multi-signature address we mentioned earlier.
Alice will receive the tokens right away, but Bob will have to wait until the timelock expires to spend from the multisig address. Remember we mentioned above that another condition must be met before Alice can immediately access the same funds? She needed a secret she didn’t have at the time. But now she knows the secret – the second round of deals has just been created and Bob leaks it.
While Bob can only wait for the timelock to expire, Alice can remove all the funds. This punitive mechanism ensures that participants do not try to cheat, or counterparties will get their tokens.
Channel payment
We talked about this issue before, the connection between channels can be established, otherwise the Lightning Network cannot effectively support the payment function. Just imagine if we would actually save $500 in the same coffee shop just to have a drink every day for the next few months?
Actually there is absolutely no need to do so. Alice and Bob open the channel, and Bob and Carol have established the channel, so Bob can pay them both through the channel. By traversing multiple “hops” in this way, Alice can pay everyone in the path.
Intermediaries play a role in the channel and will charge a small fee, but not mandatory. The Lightning Network is still in its nascent stage, and the fee market has yet to take shape. Many expect to be able to charge fees based on liquidity.
In the base chain, users pay fees based on the block space occupied, but not the value of the transfer. That is, paying $1 is the same as paying $10 million in fees. In contrast, the Lightning Network has no block space to speak of.
However, there is the concept of local balance and remote balance. A local balance is an amount that a party can “push” to the other end of the channel, while a remote balance is an amount that a counterparty can push back to the local party.
Another example. Let’s take a closer look at one of the above paths: Alice <> Carol <> Frank.
Alice <> Carol and Carol <> Frank each have a total capacity of 1 BTC. Alice’s local balance is 0.7 BTC. Everyone settles in the blockchain at this time, Alice receives 0.7 BTC, and Carol receives a remote balance of 0.3 BTC.
Suppose Alice wants to send 0.3 BTC to Frank, she will push 0.3 BTC to the side of Carol’s channel. Carol then pushes 0.3 BTC from his local balance to Frank via the channel. Ultimately, Carol’s balance remains the same: +0.3 BTC from Alice and -0.3 BTC sent to Frank cancel each other out.
Carol’s role as Frank’s intermediate connection does not lose value, but the flexibility of his own funds management becomes poor. It can be seen that she currently spends 0.6 BTC in the channel with Alice, but can only spend 0.1 BTC in the channel with Frank.
We imagine a situation where Alice is only connected to Carol and Frank is connected to a wider network. Previously, Carol could send a total of 0.4 BTC to others through Frank, but now she has only 0.1 BTC at one end of her channel to push out.
In this case, Alice is actually cannibalizing Carol’s liquidity. Without any incentive, Carol didn’t want to put herself at a disadvantage. So she might offer ” I will charge 10 satoshis for every 0.01 BTC output from my channel “. This way, the higher the local balance Carol discards in the “stronger” path, the more she earns.
As mentioned earlier, there is no de facto fee requirement here. Some people are not worried about poor liquidity, and some people just want to open a channel directly with the receiver.
Limitations of the Lightning Network
If it turns out that the Lightning Network can solve all of Bitcoin’s scalability problems, everyone will be happy. Unfortunately, the Lightning Network has shortcomings that hinder its own development.
Availability
For beginners, Bitcoin is not the most intuitive system, addresses, fees, etc., may be confusing. However, wallets abstract away these complex contents and provide users with operations that are more similar to existing payment systems. We can let others download smartphone wallets and send them tokens. That way they’ll be more than willing to do it.
The Lightning Network can’t do that right now, and its smartphone app selection is pretty limited. Generally speaking, Lightning Network nodes need access to Bitcoin nodes in order to be fully utilized.
After setting up the client, the user needs to open the channel to make payment. This process is time-consuming, especially when newcomers are exposed to concepts such as “inbound/outbound capacity”.
Therefore, the Lightning Network needs to be continuously improved to lower the entry threshold and allow users to have a smoother experience.
Fluidity
A major criticism of the Lightning Network is that users’ transaction capabilities are limited. Personal spending cannot exceed the amount locked in the channel. If someone wants to spend all the funds and transfer all the funds of the channel to the remote balance, the channel must be closed. Alternatively, passively wait for others to pay through the channel, but this is not ideal.
Individual paths are limited by the total channel capacity. Take the previous Alice <> Carol <> Frank as an example. If Alice and Carol’s channel has a capacity of 5 BTC and Carol and Frank’s capacity is only 1 BTC, then Alice can never send more than 1 BTC. Even so, all balances need to be on the Carol side of the Carol <> Frank channel for the Lightning Network to function properly. This severely limits the amount of money that can be transferred through Lightning Network channels, which in turn affects the usefulness of the network.
Centralized hub
Based on the aforementioned issues, there are concerns that such a network would spawn a large number of “hubs,” large, closely-connected entities with strong liquidity through which all large payments pass.
Obviously, this development momentum is not a good phenomenon. Centralized hubs weaken the system, as these entities going offline can severely disrupt the relationship between users. Furthermore, since only a few points are traded, the risk of censorship increases.
The current state of the Lightning Network
As of March 2022, the Lightning Network is functioning normally, with over 35,000 online nodes, over 85,000 active channels, and a capacity of over 3,570 BTC.
Among the many different node implementations, Blockstream’s c-lightning, Lightning Labs’ Lightning Network Daemon, and ACINQ’s Eclair are particularly popular. For less tech-savvy users, many companies have introduced plug-and-play nodes. Users can start using the Lightning Network simply by plugging in the device.
Conclusion
The Lightning Network mainnet went live in 2018, and while many believe it is still in beta, the network is already showing incredible momentum.
Currently, only users with a certain level of technical proficiency operate Lightning Network nodes, so the network still needs to overcome some usability hurdles. With the vigorous development of the network, the barriers to entry are gradually lowering.
As long as the problem is solved smoothly, the Lightning Network will become an integral part of the Bitcoin ecosystem, greatly improving scalability and transaction speed.
Please check YObit official website or contact the customer support with regard to the latest information and more accurate details.
YObit official website is here.
Please click "Introduction of YObit", if you want to know the details and the company information of YObit.
Comment by Hans
April 24, 2024
as I am trading here various assets, for me it's the most important feature. i mean, flexibility in tradable markets. i alternate trading styles, meaning that sometimes I trad...