This article comes from the BFTF Technology Community Alliance, author: BFTF Technology Community Alliance, compiled by: Fangyuan, published with authorization.
Introduction: The Lightning Network is an improvement scheme for the Bitcoin network proposed to solve the congestion problem of the Bitcoin network. The essence of the Lightning Network is to use the Bitcoin network as a settlement network. After a channel is established between two nodes, all transactions can be completed off-chain. The author of this article gives a comprehensive introduction to the Lightning Network, which is very suitable for blockchain practitioners to read.
If you've ever used Bitcoin, you've probably experienced transaction (confirmation) times of up to an hour (or worst case up to a day). At times of high transaction volume, the Bitcoin network once had a backlog of over 150,000 unverified transactions, and it is now the norm. The combination of such a long transaction confirmation time and high fees makes it difficult to use Bitcoin in micropayment scenarios (for example, if you spend 30 yuan for a meal at noon, the fees required by miners to package transactions may be much higher than this number).
Lightning Network can help us solve this problem. The Lightning Network is the brainchild of Thaddeus Dryja and Joseph Poon, who submitted a white paper on the Lightning Network in 2015. If you are not interested in reading long papers, I will briefly introduce the principles and processes of Lightning Network in this article.
What is the Lightning Network?
Essentially, the Lightning Network is a method for bitcoin users to exchange monetary value from the bitcoin blockchain. This is achieved through some complex scripts that interact with the Bitcoin blockchain, and it allows for quick payments for small transactions (and low transaction fees). The Lightning Network is a necessary tool to improve the scalability of the Bitcoin blockchain if Bitcoin is to become a viable payment method in the future. This practice can be extended to cross-chain transactions. Such value swaps are similar in practice, except they happen between two different currencies/blockchains. We discuss atomic swaps in more detail here.
This is the end of the introduction to the role and introduction of the Lightning Network. Next, we will enter the stage of introducing the details of the Lightning Network.
How does the Lightning Network work?
Open two-way payment channel
If you want to use the Lightning Network, you need to set up a payment channel. Payment channels are the transactional pathways for transferring value across the Lightning Network. To open a payment channel, a new transaction needs to be created on the Bitcoin blockchain.
"And yet I thought you said all of this happened off-chain?" Don't worry, the Lightning Network is off-chain, but you first have to let the Bitcoin network know that you're making a transaction. Once this is done, both parties to the transaction retain the balance sheet on the channel. Every time funds are moved, the transaction and updated account balances are recorded in this ledger, and after you make a payment on the channel, the final result can be broadcast to the blockchain.
multisig wallet
So if payment channels happen off-chain, where/how are the funds managed and how are they recorded on the Bitcoin blockchain? In order to use a payment channel, both parties need to send their funds to a multisig wallet address.
Suppose Molly and Steve bet on the outcome of the Super Bowl. They each wager 1 BTC and want to make sure the other party holds his/her transaction, so they deposit the funds in a multisig wallet. A multi-signature wallet functions like a deposit safe, and a set of private keys for a transaction can allow either party to access funds. Funds will remain locked in the wallet until:
Both Molly and Steve signed the final deal
one party completes the final transaction, or
The time limit is reached and the transaction is automatically submitted. Once this happens, the funds are transferred back to the personal wallets of both parties.
To successfully set up a multisig wallet, Molly and Steve both create a value (essentially a key that unlocks the transaction), which they then use to create a hash and send to each other. Mastering these is critical to understanding how commitment transactions work later.
Once Molly and Steve have deposited their respective funds into the multisig wallet, they can create what is called a payment channel and broadcast it to the Bitcoin blockchain. Once broadcast, the funds are managed using a series of commitment transactions.
Transferring Money Through Commitment Transactions
In the end, Molly won the bet, and she won 0.5 bitcoins. In order to start transferring this wealth, both Molly and Steve will update their respective balances in the payment channel by signing a commitment transaction. Commitment transactions divide funds between two participants according to mutual agreement. In essence, these transactions are like IOUs, which are actually paid (referred to on the Bitcoin blockchain) once the payment channel is closed.
For example, Molly signs a transaction that sends 1.5 BTC to herself and 0.5 BTC to a new multisig address. She then signs this transaction and sends its hash to Steve. In turn, Steve signed a commitment transaction similar to Molly's, except that he sent .5 BTC to himself and 1.5 BTC to another multisig address. He then signs the transaction and sends the hash of this transaction to Molly.
a) 2BTC in the original multisig wallet, b) .5 BTC in a multisig wallet, paid to Steve, and c) 1.5 BTC in a multisig wallet to Molly. In fact, once any party sends its respective transaction hash, the balance sheet in the payment channel will be updated. So in this way, we have a transaction without using the Bitcoin blockchain.
Money in the wallet can only be unlocked under three conditions:
lock time is up
Either party unlocks the funds from the multisig wallet they set up via the value (key), or
Both parties sign the transaction together.
Note that if a party decides to close the payment channel and sign the transaction separately, he/she will have to wait until the predetermined time (specified by the contract) set when the transaction was signed to receive his/her funds. This may sound excessive, but cheating must be prevented by such means.
Recurring payment/renewal channel
What if Molly and Steve want to keep updating channels or do multiple exchanges?
Suppose Steve is paying Molly for a recurring service, such as a haircut. Steve deposits 0.2 BTC into their multisig wallet, and after each haircut, he signs a commitment transaction to Molly, sending 0.001 BTC to the new multisig address. To do this, he has to repeat what we just did, opening a new transaction on the blockchain.
Therefore, to process recurring payments, the account balance in the multisig address needs to be updated each time. To do this, every time Steve gets a haircut, he pays Molly by putting a new sum into a multisig wallet he has set up. But in doing so, he created a new value and a new hash for this new transaction. Molly does the same thing, when two parties exchange a new hash, they also exchange the old value of the previous transaction (note that instead of exchanging the hash, the hash of the old transaction was exchanged last time).
This ensures that neither party can cheat the other. If Steve tries to trick Molly by broadcasting old transactions when the payment channel is closed, he's in trouble.
For example, if Steve broadcasts the original state when closing the channel, he signed the original transaction (one BTC each for Molly and Steve). Because Molly has the key to the previous transaction, she can punish Steve. More importantly, Steve has to wait until the lock time to get the money, while Molly can get the money right away. So if she finds out that Steve broadcast the raw data, she can simply take 2 BTC in the multi-signature wallet (since she has the key for this transaction and, therefore, is able to unlock its funds).
So if one party tries to cheat the other, the counterparty gets all the funds. This penalty is intended to deter bad actors from abusing the allocation of funds from payment channels.
Additionally, node operators and miners who spot such foul play can act on her behalf if Molly is not online. In compensation, these they will receive a certain bounty.
Close the payment channel
When Molly and Steve are ready to close the channel, they simply sign a transaction with their private keys, broadcasting their final account balances to the blockchain. At this point, miners will verify and store it in the blockchain. Like the channel opening transaction, this closing channel transaction needs to interact with the Bitcoin blockchain.
Alternatively, the parties can also set an expiration date for the term of the contract. For example, using the nLockTime algorithm, they can guarantee that the payment channel will be open for 30 days, after which the channel will be closed and the final balance will be broadcast to the blockchain. However, whenever parties want to update their balances, the due date is reduced. So, if Molly and Steve bet on multiple football games during a season, the nLockTime contract would have a new, shortened expiration date each time a bet was placed (e.g. if the first committed deal would be completed within 30 days, The second transaction will expire on day 29, then the third transaction will expire on day 28, and so on).
The purpose of the nLockTime contract is simple: it keeps account balances up to date and prevents one party from forging bills. As we discussed before, every time a commitment transaction is agreed upon, the old account balance is exchanged for a new account balance, and each party records this new balance along with the old private key. If either party attempts to deceive the other party, the fraudulent party will be penalized.
Multi-channel payment and HTLC
“What if Molly and Steve want to send bitcoins to each other, but they don’t have a payment channel open between them?” They can go through a middleman.
It turns out that both Molly and Steve have payment channels open with Chuck, so they don't need to open a new channel, but trade through Chuck.
Now, this is a trustworthy transaction in theory, the trick is to do it in a safe manner. To this end, the Lightning Network implements Hashed Time Lock Contracts (HTLC).
Molly wants to pay Steve 0.5 BTC. To do this, Steve has to create a value (essentially a confirmation code or key). He then creates a hash of this value and sends it to Molly. To simplify this written illustration, we'll use V for value and H for hash.
When Molly gets the H, she shares it with Chuck. If Chuck reveals V, Molly will send Chuck 0.5 BTC. To get V, Chuck sends Steve 0.5 of his own BTC in exchange for V. Once he has this value, he sends V to Molly and receives 0.5BTC. This effectively transfers 0.5 BTC to Steve from Molly.
The specific process is as follows:
Steve creates V and H → Steve sends H to Molly → Molly sends H to Chuck → Chuck sends BTC to Steve → Steve sends V to Chuck → Chuck sends V to Molly → Molly sends BTC to Chuck
Therefore, the value (V) is used as a confirmation code/key for the hash (H), which signifies receipt/lock of the transaction.
"But how does Molly know that the V that Chuck gave her is legal, what if Steve ran away after Chunck paid the money?"
Just as nLockTime makes it mandatory for everyone to be honest in a two-way payment channel, a hashed timelock contract makes all parties accountable for it.
With HTLCs, the bitcoin funds being traded are again locked in a multisig wallet and can only be unlocked after a value (V) and hash (H) are provided either a) or b) the contract expires after a timeout period.
Effectively, this means that when Molly and Chuck come to an agreement for Molly to pay Steve, she uses HTLC to lock the bitcoin she owes Chuck in a multisig wallet. Once Chuck pays Steve and receives V, he can enter V and H into the HTLC to get the bitcoin paid by Molly. Alternatively, if Chuck fails to complete the transaction and the contract expires after a week, Molly's bitcoins will be released and re-entered into her private wallet.
The same action happens with Chuck and Steve's own payment channels. Chuck can't hand over his bitcoins to Steve until Steve reveals V. Once Steve reveals the V, Chuck will have access to funds from Molly and Steve will receive Chuck's BTC.
In theory, this process could run with multiple payment channels and multiple people.
Summary: Why the Lightning Network Matters
It's a complex topic, and it's hard to explain in simple terms, but reading this is true love.
Overview: The Lightning Network is an off-chain system that allows individuals to exchange bitcoins multiple times without recording all of those transactions on-chain. Only two transactions (and opening and closing) are recorded on the blockchain, while all other transactions (as many as possible) are processed through offline nodes.
This model has several major benefits:
Efficient Micropayments: The Lightning Network is geared towards micropayments. Instead of paying exorbitant fees in excess of the value transferred, the Lightning Network allows users to send small amounts of currency to each other without going directly through the Bitcoin network. They still need to pay fees to node operations, but this is insignificant compared to Bitcoin network fees.
Scalability and Latency Solutions: Consistent with previous arguments, the Lightning Network will reduce Bitcoin network bloat. Reducing the number of on-chain transactions means less work for miners, which in turn means faster transaction times and lower fees. The network would run more smoothly if every transaction didn't have to be placed on the blockchain's public ledger. Additionally, Lightning Network transactions will be much faster than on-chain transactions.
Currently, the Lightning Network supports Bitcoin, Litecoin, and Vertcoin. The Lightning Network is still in beta and no mainnet launch has been confirmed at the time of publication.
