Bitcoin is often impractical to use due to the slow and expensive transactions of the blockchain, and most people use it as a basis for trading on stock exchanges or as digital gold. The concept known as Lightning Network (LN) is advertised as a solution to this scalability problem.
Basics of Lightning Network
The Lightning Network was first described in early 2015 in a corresponding white paper. It was designed by Joseph Poon and Thaddeus Dry, but in fact the author of Bitcoin himself, Satoshi Nakamoto, is behind the concept as we can see from his 2013 email to Mike Hearn.
In short, LN is based on the principle of payment channels which are actually multiple signature wallets. Multi sig wallets are Bitcoin addresses where more private keys are needed to spend funds, ie. multiple users must authorize sending at the same time. You can compare multi-sig wallets to bank vaults that require turning two keys at the same time to open.
For example, a multi-sig wallet can be a shared bitcoin address of a household. Husband and wife both have a common BTC balance, and to spend funds from the same they both need to confirm the transaction with their private key otherwise the funds cannot be spent.
The purpose of the payment channel is to make smaller payments on a regular basis and to avoid high transaction costs. For example. employer-employee, consumer-provider of services such as electricity or water, customer-cafe, etc. The idea is that the customer can open a payment channel with his cafe and then regularly transfer payments to him as needed without waiting for confirmation of transactions (currently it is necessary to wait at least 10 minutes, and usually 60 minutes when spending Bitcoin in a store).
How does the Lightning Network work?
Similarly to blockchain explorer, there’s a Lightning explorer.
Now lets explain by example, step by step.
Our imaginary scenario is this: Bob wants to pay Alice to write him articles. The deal is 10 BTC in total for 100 articles, or 0.1 per article.
In a traditional Bitcoin system, this would require 100 transactions, each of which would take an average of an hour and cost from $ 1 to $ 100, depending on network congestion. To save on costs and time, they opt for LN.
Step 1: Opening the channel
Bob creates a regular Bitcoin transaction on the main chain in which he defines the following:
- with whom he opens the channel
- how many BTC he wants to send to that channel (10 BTC)
- after how much time (eg a week) has the right to pick up the sent 10 BTC back to his own address if Alice does not respond
The latter is actually a separate sub-transaction in the main transaction with a “timelock” function that says that despite being confirmed by both required participants, it cannot be valid until the set time expires.
So, Bob sends Alice two transactions: one in which he suggests opening a payment channel and sends 10 BTC to the multi-sig address created by the opening, and the other in which he sends those 10 BTC back to himself but only after 7 days if Alice does not respond.
Step 2: Accepting the channel opening
Alice receives two proposed transactions from which it can be seen that Bob is offering 10 BTCs at the multi-sig address for the two of them with a week of lockout for non-reporting, after which the funds are returned to Bob. Alice accepts this and signs the transactions. Transactions then signed sit in the LN and wait to be sent to the blockchain.
Only when the transaction is signed by both parties required for confirmation is that transaction sent to the main Bitcoin blockchain.
It is important to define two terms: signed transaction and sent transaction. The one that both nodes accept but do not send to the network is signed. The sent transaction is sent to the blockchain and opens / closes the payment channel.
Signing and sending the first opens the channel and causes the transfer of 10 BTC from Bob’s account to the multi-sig account that was created. The signing of the second, although immediately confirming the transfer of all 10 BTCs back to Bob’s account, becomes active only after a week.
Alice and Bob have a week to do the first part of the job.
Step 3: Sending the first transaction
Alice wrote the first article and Bob likes the article. He pays 0.1 BTC as agreed by doing the following:
- generates a new transaction in which it says “From a multi-sig address I send Alice 0.1 out of a total of 10 BTC and 9.9 BTC I send to myself”, and with this transaction generates another: “If Alice does not confirm this transaction within a week, I have the right to take all 10BTC , including 0.1 BTC not yet sent, back to my account ”
- sends Alice transactions for signature via the Lightning Network node, without sending them to the main blockchain. Let’s remember: transactions are sent to the main blockchain only when both parties sign and send them.
- Alice receives transactions and checks the terms: “0.1 BTC for the article, OK, I have a week to accept and I will receive 0.1 BTC, which means I have a week to submit a new article.”
On Bob’s side, this balance has been signed and is ready for commitment on Alice’s side.
Alice doesn’t have to sign the transactions that Bob resends to her. Alice is by no means allowed to sign and send this bulk transaction to the blockchain but leaves it “on the table” so as not to cause the transaction to settle and close the payment channel.
This “leaving on the table” is actually the part that solves the Lightning Network node, ie. The LN wallet used by Alice – the software accepts and signs these terms, but on the Lightning Network layer, not on the main layer of the Bitcoin blockchain. After confirming that it accepts, the new state of the multi-sig wallet becomes current.
The transaction in the current state is immutable and the conditions described in it must be met before any change occurs: either the week must expire, or Alice must confirm (sign and send the transaction) and download only 0.1 BTC out of a total of 10 in the channel.
Step 4: Sending another transaction
Alice is sending a new article in 3 days and it is up to Bob to send a new 0.1 BTC. Since it is not possible to change the last transaction but it is only possible to generate a newer one that has a more up-to-date status, Bob cannot send another 0.1 BTC but does the following:
Bob generates a new transaction in which he says: “From a multi-sig address I send Alice 0.2 out of a total of 10 BTC, and 9.8 BTC I send to myself.” In addition to this transaction, it generates another one: “If alice does not send this transaction within a week, I have the right to download all 10 BTC from the channel.”
Alice now has the opportunity to either sign the transaction and send it, take over 0.2 BTC and thus end the employment, or continue the employment, send further articles and receive new incremental transactions, or not react for a week and lose everything.
Basically, LN is a practical solution to some problems that do not currently exist in the Bitcoin network. Does that make it an effective way to scale BTC? We feel that not because of some seemingly unsolvable problems that we will study in detail later, but we believe that it is still an interesting upgrade to the standard protocol.